索引过多会导致写入性能断崖式下跌、优化器误判和磁盘空间浪费；应通过sys.schema_unused_indexes等视图识别并删除未使用、冗余索引，删前需评估锁影响、主从一致性及业务查询回归。
索引字段过多，不是“慢一点”的问题，而是写入性能断崖式下跌、优化器开始“乱猜”、磁盘空间被 silently 吞掉的系统性风险。
INSERT/UPDATE/DELETE 变慢八成是因为索引太多
每多一个二级索引，INSERT 就得多执行一次 B+ 树插入、多维护一次页分裂逻辑、多写一次 undo log 和 redo log。这不是线性增长——当表有 5 个以上二级索引时，单行写入开销常翻 2–3 倍。
常见错误现象包括：
-
SHOW PROCESSLIST里大量语句卡在updating状态 - 慢查询日志中
INSERT频繁进入 top 10 - 监控指标
Innodb_row_lock_waits突增
更隐蔽的是：高并发下多个线程往相同前缀（如订单号前缀固定）插入时，会因唯一性检查加剧锁等待，甚至触发死锁。
优化器选错索引往往源于索引数量爆炸
MySQL 优化器在生成执行计划前，要评估每个可用索引的成本。索引越多，它要计算的路径就越多；尤其当存在多个可覆盖相同 WHERE 条件的索引（比如 idx_a、idx_a_b、idx_a_b_c），优化器可能反复比较、误判统计信息偏差，最终选错索引或退化为全表扫描。
真正难缠的是：ANALYZE TABLE 更新统计信息的频率常跟不上数据变化速度，导致索引基数（Cardinality）长期不准——优化器不是不想选对，是“瞎猜”。
典型表现：
-
EXPLAIN显示type: ALL或key列为空，但明明有匹配索引 - 查询
SELECT * FROM orders WHERE user_id = 123 AND status = 'paid'，本该走idx_user_id_status，却走了idx_created_at
怎么判断哪些索引该删，别靠经验猜
直接查系统视图，看真实使用痕迹：
- MySQL 8.0+：运行
SELECT * FROM sys.schema_unused_indexes，列出近 30 天完全没被任何查询命中的索引 - 更底层：用
SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage WHERE count_star = 0，连 DML 触发的索引更新都算进去 - 手动验证：对关键 SQL 执行
EXPLAIN FORMAT=JSON，检查输出里的used_columns字段，确认实际生效的索引列是否和你建的一致
注意冗余场景：WHERE a = ? AND b > ? ORDER BY c 这类查询，idx_a_b_c 能覆盖全部，idx_a 和 idx_b 就是冗余的；已有 idx_user_id_status_created，再单独建 idx_user_id 或 idx_user_id_status 也是白占空间。
删索引前必须绕开三个坑
线上大表直接 DROP INDEX 风险极高：
- 先查锁影响：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_query LIKE '%DROP INDEX%'，避免长事务阻塞 - 确认
binlog_format是ROW，否则 DDL 可能导致主从不一致 - 对核心表，优先用
pt-online-schema-change --alter "DROP INDEX idx_name" D=db,t=tbl替代原生 DDL，避免锁表
真正难的不是删，而是删完之后——业务方突然发现某个报表接口变慢了。所以删之前，一定用 slow_query_log + min_examined_row_limit = 1000 拉一周真实 SQL 流量，重点盯那些刚被删掉索引字段参与查询的语句。
