MySQL索引清理：如何安全删除“僵尸”索引并规避性能风险
数据库表越用越臃肿，除了数据增长，那些建了又忘、早已失效的“僵尸”索引也是隐形负担。它们不仅占用空间，还会拖慢写操作。但删索引这事儿，手起刀落之前，得先搞清楚三个核心问题：它真的没用了吗？删除过程会卡住吗？删了之后会不会有隐藏的坑？
怎么安全确认一个索引是否真没被用过
MySQL本身不会主动告诉你“这个索引最近没人碰”。所以，光看表结构或者SHOW INDEX就下结论，风险极高。稳妥的做法，是结合系统统计和实际查询路径，做一次交叉验证。
具体可以分三步走：
- 查系统视图：在MySQL 8.0及以上版本，重点查看
performance_schema.table_io_waits_summary_by_index_usage。如果某个索引的COUNT_STAR和COUNT_READ长期都是0，那它很可能在“睡大觉”。不过要注意，这个功能默认可能没开，得先确认performance_schema和相关消费者（consumer）已经启用了。 - 跑执行计划：把业务里所有高频的
SELECT、UPDATE、DELETE语句都用EXPLAIN过一遍。重点看key字段，目标索引的名字有没有出现。这里特别容易漏掉那些包含OR、IN或者对列用了函数的查询，它们常常会“绕开”你预想的索引。 - 翻慢查询日志：去慢查询日志里搜一下，有没有语句用到了这个索引（可以搜索
key: index_name或Extra: Using index配合索引名）。历史记录往往能暴露一些低频但关键的使用场景。
简单来说，安全确认索引未被使用，就得靠这三板斧：查performance_schema看统计、用EXPLAIN验高频SQL、翻慢日志找历史痕迹。
DROP INDEX 时为什么有时卡住或报错
明明语法没错，一执行DROP INDEX要么半天没反应，要么直接报错。这通常不是命令的问题，而是MySQL在删除前需要获取元数据锁（MDL），并在高并发写入时，这个等待过程就被放大了。
常见的几种情况：
- 报错“Can‘t DROP； check that column/key exists”：最常见的原因是指定的索引名拼错了，或者大小写不匹配（尤其在Linux系统上，表名和索引名默认是区分大小写的）。
- 命令长时间无响应：这时候很可能有其他事务正持有该表的
MDL_SHARED_WRITE锁，比如一个运行了很久还没提交的UPDATE事务。DROP INDEX作为DDL操作，必须排队等这个锁释放。 - 报错“Error on rename...”：这类错误多发生在MyISAM引擎表上，或者在MySQL 5.7以下版本中误操作了主键索引（记住，主键索引不能用
DROP INDEX命令删除，得用DROP PRIMARY KEY）。
比较稳妥的做法是，在执行删除前，先跑一下SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME = 'tbl_name';，看看当前有哪些锁在占用目标表，再决定是否要终止阻塞的事务。
删除索引后性能反而变差？这些隐性依赖要提前扫
索引的作用远不止加速WHERE条件查询。它还可能默默地支撑着排序（ORDER BY）、分组（GROUP BY）、覆盖索引扫描，甚至是外键约束和数据唯一性。没摸清这些隐性依赖就动手，很容易踩坑。
下面这几个场景尤其要警惕：
- 忽略了排序和分组：你以为一个索引只用在某个
WHERE条件里，结果删掉后，某个关键的ORDER BY created_at LIMIT 10查询，执行计划从快速的索引排序退化成了全表文件排序（filesort），性能直线下降。 - 破坏了唯一性约束：删除了唯一索引（
UNIQUE KEY），数据库层面就不再阻止重复数据插入。如果应用层没做二次校验，脏数据就进来了，一致性直接被破坏。 - 影响了外键性能：MySQL要求外键列必须要有索引。如果删除了外键字段上的索引，后续对父表或子表的关联插入、更新操作可能会变慢，甚至在某些情况下报错
ERROR 150。 - 误判了联合索引的“冗余”：比如表上已经有了联合索引
(a,b,c)，又有一个单独的(a)索引。单看查询，后者似乎冗余。但在某些WHERE a = ? ORDER BY b的场景下，优化器可能会认为单列索引(a)的排序成本更低，从而选择它。删掉这个“看似冗余”的索引，可能就让优化器选错了路。
批量清理索引时如何控制风险
清理索引最忌贪多求快，尤其是对线上核心表。MySQL删除索引的本质是修改表结构，其耗时和锁表现因引擎和版本差异巨大，必须分批、谨慎操作。
操作前，有几个关键判断点：
- 确认存储引擎：先用
SHOW CREATE TABLE tbl_name看清楚。对于InnoDB表（5.6+），删除二级索引通常属于ALGORITHM=INPLACE操作，相对轻量。但如果是MyISAM表，删除索引意味着要重建整个.MYI索引文件，锁表时间会很长。 - 利用新特性：MySQL 8.0+版本对删除非主键的二级索引支持
ALGORITHM=INSTANT。使用ALTER TABLE t DROP INDEX idx_name, ALGORITHM=INSTANT;语法，几乎可以做到瞬间完成，不阻塞DML。当然，前提是这个索引不是全文索引、空间索引等不支持INSTANT算法的类型。 - 预演很重要：对于大表，务必先在从库或者影子库上执行一遍删除操作。观察
ALTER语句的实际耗时，以及监控innodb_buffer_pool_wait_free等指标是否有剧烈波动。 - 删后验证：删除操作完成后，立即通过
information_schema.STATISTICS表确认索引已消失。紧接着，用EXPLAIN再次检查核心业务SQL的执行计划，确保没有出现性能退化。
说到底，删索引真正的麻烦，从来不是技术操作本身，而是“你不知道谁还在用它”。最可靠的方法，还是在操作前，把最近一周的慢查询日志和应用层的SQL调用记录都拉出来，用索引名彻底搜索一遍。很多时候，人眼比任何自动化文档都更靠谱。毕竟，线上无小事，谨慎驶得万年船。
