MySQL索引过多导致INSERT变慢的八大原因——每增加一个二级索引，INSERT操作需额外执行B+树插入、页分裂维护及undo/redo日志写入；索引超过5个时单行写入开销通常增加2–3倍。
INSERT性能下降，八成源于索引数量过多
为数据库表添加索引并非“免费午餐”。每增加一个二级索引，一次看似简单的INSERT操作，其背后都需要额外执行多项任务：向新的B+树中插入一次数据，多维护一份潜在的页分裂逻辑，并额外写入一轮undo log和redo log。因此，当一张表的二级索引数量累积到5个以上时，单行数据写入的开销增加2到3倍是常见现象。这并非理论推测，观察线上环境的典型信号即可验证：SHOW PROCESSLIST中线程频繁卡在updating状态，慢查询日志里INSERT语句持续出现，监控面板上Innodb_row_lock_waits指标突然升高——这些现象往往是索引负担过重的直接表现。
查询优化器为何也受索引过多影响
索引数量过多不仅影响写入性能，连负责制定执行计划的查询优化器也会因此陷入困境。在确定最终执行路径前，优化器需要评估每一个可用索引的成本。索引数量一旦上升，需要计算的路径组合便呈指数级增长。尤其当存在多个均可覆盖相同WHERE条件的索引时（例如idx_a、idx_a_b、idx_a_b_c同时存在），优化器极易陷入反复比较的循环，甚至可能因统计信息的细微偏差而做出错误判断，最终选择低效索引或直接退回全表扫描。另一个更隐蔽的问题是：ANALYZE TABLE更新统计信息的频率，常常跟不上数据的实时变化节奏。这导致索引基数（Cardinality）长期处于“失真”状态，使得优化器如同依靠“过时经验”进行猜测，执行计划的准确性与效率自然难以保障。
如何准确判断哪些索引应该删除
究竟哪些索引属于“无效”或“低效”索引？不应依赖经验猜测，而应让实际使用数据说话。最有效的方法是直接查询系统信息视图，分析索引的真实使用状况：
SELECT * FROM sys.schema_unused_indexes—— 若使用MySQL 8.0及以上版本，此内置视图极为直观，可直接列出过去近30天内完全未被任何查询命中的索引，堪称“闲置索引清单”。SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage WHERE count_star = 0—— 此方法更为底层，连DML操作（增、删、改）所触发的索引更新都会计入统计。若此计数始终为零，则该索引基本处于“完全未使用”状态。- 手动检查
EXPLAIN FORMAT=JSON—— 针对核心查询语句，使用此命令并查看输出中的used_columns字段。它能帮助您确认查询实际使用的索引列，与已创建的复合索引是否匹配，从而发现那些设计不当或覆盖范围不全的索引。
这里需注意一个常见的冗余索引场景：对于WHERE a = ? AND b > ? ORDER BY c这类查询，一个设计良好的idx_a_b_c复合索引即可完美覆盖查询条件与排序需求。此时，单独的idx_a或idx_b索引，极有可能成为冗余摆设。
删除索引前必须完成的三个关键步骤
即使确定了待删除的索引目标，也切勿立即执行DROP INDEX命令，尤其是在线上业务表上操作，风险较高。动手前，务必完成以下三件事：
- 评估锁影响：可执行
SELECT * FROM information_schema.INNODB_TRX WHERE trx_query LIKE '%DROP INDEX%'进行模拟观察，或评估当前活动事务，判断DDL操作是否会阻塞关键业务长事务，避免引发线上连锁故障。 - 确认复制环境配置：若数据库部署了主从复制架构，务必确认binlog格式是否为
ROW。若仍为STATEMENT格式，DDL操作可能导致主从数据不一致。 - 选择安全的在线变更工具：对于核心业务大表，强烈建议使用
pt-online-schema-change等专业在线表结构变更工具来替代原生DDL。其原理是通过创建影子表并同步数据，能最大限度避免长时间锁表，保障业务连续性与可用性。
实际上，删除索引本身的技术操作并不复杂，真正的挑战往往出现在删除之后——业务方可能突然发现某个报表查询或接口响应速度显著下降。因此，最后一道安全防线是：在最终决定删除前，务必开启slow_query_log慢查询日志，并设置如min_examined_row_limit = 1000的筛选阈值，采集至少一周的真实业务SQL流量进行回溯分析。重点观察那些引用了待删除索引字段的查询语句，确保其性能不会因此受损。毕竟，优化数据库性能的首要前提，是确保业务运行的稳定性与可靠性。
