索引过多会显著降低INSERT/UPDATE/DELETE性能，增加I/O与CPU开销，并引发冗余占用空间、优化器误选执行计划等问题；建索引前须确认字段是否高频参与查询、是否已被现有联合索引覆盖。
索引太多会导致 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)
索引不是越多越好，而是够用、精准、不重叠。最常被忽略的一点：删除旧索引比新建更难推动，所以第一刀一定要砍准。
