如何删除MySQL中错误添加的索引？通过DROP INDEX语句修复数据库性能

说实话，删MySQL索引这事儿吧，我以前踩坑也不少。
你给的文档挺全，但我想用更像我平时唠嗑的口吻说说这事儿。

比如有一次删索引，我就是用的ALTER TABLE...DROP INDEX，结果表直接锁了俩小时。
当时我直接炸毛了——那业务高峰期根本没法用啊！后来才知道，那会儿用的还是MySQL 5 .5 说实话，现在谁还用这么老的版本啊？但当时这事儿让我明白一个道理：删索引前必须知道你用的MySQL版本，这直接影响你能不能用在线DDL。

说到验证索引，我有个特别具体的经验。
之前有个项目，用户表有个索引user_id_idx，但EXPLAIN一看，所有查询都直接用主键索引了。
我一开始以为这索引没用，结果跑了一周监控，发现偶尔有慢查询居然用到了它。
后来查到是某个第三方报表工具在半夜跑统计时用到了这个索引。
这事儿告诉我，索引统计信息不能只看读计数低就随便删，得结合业务场景。

再说复合索引，这绝对是个坑。
我之前接手过一个系统，表上有col1 , col2 , col3 的复合索引，结果业务逻辑只查col1 按理说col1 独立索引就够了，但那业务逻辑特别复杂，删了索引后查询直接变慢了5 0%。
我当时真是服了——这业务场景下，复合索引里最左边的索引居然不是最优的。
所以现在我删复合索引前，都会在测试环境用EXPLAIN跑遍所有可能用到的查询组合。

至于无锁操作，我最近在用Percona Toolkit的pt-online-schema-change，这玩意儿确实神。
上次删一个百万行表的索引，在生产环境几乎没感觉延迟。
但要注意，这需要主从复制，而且操作前要确认从库延迟不超过5 分钟，不然数据不一致就完蛋了。

最后说个冷知识。
InnoDB表删索引后，空间不会立刻回操作系统，得靠OPTIMIZE TABLE。
我有个客户就是因为没运行OPTIMIZE，结果磁盘空间一直没满，系统管理员还问我为啥表越来越小。
说实话，这种细节必须记牢，不然运维会揍你。

总之，删索引前多跑几遍EXPLAIN，备份数据，确认版本，这些比什么总结都管用。

MySQL当中如何删除某个字段的唯一索引或者修改该字段的唯一索引为普通索引

等等，我昨天下午在公司的办公室里，对着电脑屏幕调试数据库，就是遇到这个问题。
当时表里有个字段，本来设了唯一索引，后来业务需求变了，要改成可重复的。
我纠结了好一会儿，最后还是决定用第一种方法，直接修改字段定义。
写了个SQL语句，把那个字段的数据类型改了，然后MySQL就自动把索引给调整了。
整个过程挺快的，就几分钟，但心里还是有点虚的，生怕出什么岔子。
毕竟数据库这东西，稍微不小心，数据就乱套了。
所以还是得先备份，再操作，这是老规矩了。
不过话说回来，为啥要改这个字段呢？这背后还有更复杂的故事...

mysql怎么删除index索引

DROP INDEX height ON tb_stu_info; 这就是坑，别忘加ON。

ALTER TABLE tb_stu_info2 DROP INDEX height; 索引删了，查询变慢，看业务要不要。

SELECT FROM information_schema.STATISTICS WHERE TABLE_NAME='tb_stu_info'; 删后用这个查确认。

别用ALTER干小事，单独DROP更快。

mysql删除索引索引

结论：直接用ALTER TABLE或DROP INDEX删除索引。

ALTER TABLE table_name DROP INDEX index_name; 适用所有版本，可同时改表结构。

DROP INDEX index_name ON table_name; 仅MySQL 5 .1 +可用，语法简单，功能单一。

注意：删除前确认索引是否常用。
覆盖索引或主键索引，删了会全表扫描。
EXPLAIN分析，看删除后还用不用其他索引。

版本问题：5 .1 前不能用DROP INDEX。
大表删除重建，耗CPU I/O，晚点弄。
别乱删，索引没了查询慢。