索引会显著拖慢INSERT/UPDATE/DELETE操作，因每增一个索引，写入时就要多执行一次B+树维护（含页分裂、指针调整、唯一性校验等），5个索引即1次主键写入+5次索引插入，导致耗时跃升、锁等待增多、解析开销加大，并占用大量磁盘与内存资源。
INSERT/UPDATE/DELETE 变慢不是错觉，是索引在同步更新
每加一个索引，写操作就要多一次 B+ 树维护。比如 INSERT 一行数据，有 5 个索引，MySQL 就得执行 1 次主键写入 + 5 次索引插入——含页分裂、指针调整、唯一性校验（如果是唯一索引）等完整流程。
常见错误现象包括：SHOW PROCESSLIST 中大量线程卡在 update 或 insert 状态；innodb_row_lock_waits 指标突增；单条插入耗时从 0.2ms 跳到 2ms 以上。
- 普通索引：每次写入需在对应 B+ 树中插入一条记录
- 唯一索引：额外增加重复值校验，I/O 和 CPU 开销更大
- 长字段索引（如
VARCHAR(255)）：索引页更易膨胀，树高增加，进一步拖慢写入
优化器选索引会“选择困难”，不是越多越容易命中
MySQL 查询优化器需要评估所有可用索引，生成最优执行计划。索引数量从 3 个升到 8 个，候选路径组合数可能翻倍，导致两个后果：
- 解析时间变长：每个查询启动时都要做更多代价估算，
query_time中的 parse 阶段占比上升 - 误选风险提高：在高基数、低区分度字段上建了多个相似索引（如
(user_id)和(user_id, status)），优化器可能跳过更优的那个，甚至退化为全表扫描
你可以用 EXPLAIN FORMAT=TRADITIONAL 对比不同索引存在时的 key 字段变化，验证是否真被用了。
磁盘和内存成本是实打实的，不是“反正硬盘便宜”
每个索引都是一棵独立的 B+ 树，单独占用磁盘空间和 Buffer Pool 缓存。实际观测中，5 个索引常使索引总大小达到数据本身的 1.5–2 倍。
查索引空间开销的可靠方式是：
SELECT table_name, index_name, ROUND(stat_value * @@innodb_page_size / 1024 / 1024, 2) AS size_mb FROM mysql.innodb_index_stats WHERE database_name = 'your_db' AND table_name = 'your_table';
- 数据量 10GB 的表，5 个索引可能额外占 15–20GB 磁盘
- InnoDB 缓冲池要缓存索引页，每 GB 索引建议预留 1.5GB Buffer Pool，否则容易引发频繁刷脏页
- 备份与恢复时间直接受索引体积影响，
mysqldump或物理备份都更慢
冗余索引比“没索引”更危险，清理比新建更关键
很多表的索引数量超限，不是因为业务复杂，而是历史遗留的冗余索引没清理。例如：
- 已有联合索引
(a, b, c)，又单独建了(a)或(a, b)—— 后者完全被覆盖 - 字段
status区分度极低（如只有 0/1），却建了单独索引，几乎从不被EXPLAIN选中 -
CREATE INDEX语句没加命名，导致后期无法快速识别用途，不敢删
真正该关注的是 information_schema.STATISTICS 和 performance_schema.table_io_waits_summary_by_index_usage（MySQL 8.0+），看哪些索引 COUNT_STAR = 0 或长期未被访问。删错索引的风险远高于少建一个。
6 个是经验值，不是魔法数字；但超过这个数，你得能说清每一个索引服务的具体查询语句、QPS 占比、以及它不可被其他索引替代的理由。否则，它大概率只是在默默拖慢你的写入、吃掉你的磁盘、干扰优化器判断。
