索引太多会导致 INSERT/UPDATE/DELETE 变慢
每新增一条记录，MySQL 不仅要写数据页，还要同步更新所有相关索引的 B+ 树结构。索引越多，写操作需要维护的树就越多，磁盘 I/O 和 CPU 开销直线上升。
INSERT INTO users (name, email, status) VALUES ('Alice', 'a@b.com', 1);如果 users表上有
idx_name、
idx_email、
idx_status、
idx_name_email四个索引，这条语句实际会触发至少四次 B+ 树插入（含可能的页分裂），而不仅是写一行数据。 单条
INSERT的耗时可能翻倍甚至更高，尤其在高并发写入场景下明显卡顿
UPDATE修改了被索引的列（如
UPDATE users SET email = ? WHERE id = ?），会同时触发聚簇索引 + 所有二级索引的定位与更新
DELETE同样需先通过索引定位，再逐个清理各索引中的对应项，碎片化加剧
冗余索引占用大量磁盘空间且无实际收益
比如已有联合索引
idx_user_id_status_created（字段顺序为
user_id, status, created_at），再单独建
idx_user_id或
idx_user_id_status就是冗余——前者能完全覆盖后两者的所有查询需求。这类索引不仅白占空间，还拖慢备份、主从同步、
ALTER TABLE等后台任务。 每个索引都是独立的 B+ 树，存储重复的
user_id值，表越大浪费越严重
SHOW INDEX FROM users可查出全部索引，但无法自动识别冗余；需人工比对字段前缀和顺序 使用
pt-duplicate-key-checker（Percona Toolkit）可辅助发现部分冗余，但不能替代逻辑判断
优化器可能选错执行计划
索引数量暴增后，MySQL 查询优化器评估成本的负担加重，有时会因统计信息不准或代价估算偏差，放弃本该用上的高效索引，转而选择全表扫描或低效索引。典型表现是
EXPLAIN显示
type: ALL或
key列为空，但明明有匹配的索引存在。 例如查询
SELECT * FROM orders WHERE user_id = 123 AND status = 'paid'，本应走
idx_user_id_status，却走了
idx_created_at（只因该索引更“新”或统计值偏高）
ANALYZE TABLE orders可刷新统计信息，但不能根治多索引干扰下的误判问题 某些复杂查询中，优化器甚至因索引组合爆炸而跳过部分索引评估，直接降级为简单策略
建索引前必须确认的三件事
不是“能不能加”，而是“该不该加”。很多团队在开发阶段随手加索引，上线后才发现副作用远大于收益。
这个字段是否真在WHERE、
JOIN、
ORDER BY或
GROUP BY中高频出现？只在管理后台导出用一次的字段不用索引 该查询是否已通过
EXPLAIN验证走索引？没验证过的索引等于盲加 有没有现成的联合索引能覆盖它？优先扩展而非新建，例如已有
(a, b)，新加查询条件含
a = ? AND c = ?，不如建
(a, c)而非
(c)
索引不是越多越好，而是够用、精准、不重叠。最常被忽略的一点：删除旧索引比新建更难推动，所以第一刀一定要砍准。
