索引越多写入越慢，因每次增删改需更新所有相关索引b+树，导致批量导入速度下降40%以上，且占用磁盘与内存、拖慢统计分析、引发执行计划误判及主从复制延迟。
索引太多会导致写入变慢
每新增一条记录，MySQL 不仅要写数据页，还要更新所有相关索引的 B+ 树结构。尤其是 INSERT、UPDATE、DELETE 操作涉及的列上有索引时，每个索引都要做插入/分裂/合并操作。实际测试中，一张表从 2 个索引加到 8 个，批量导入速度可能下降 40% 以上。
常见误区是“读多写少就随便建”，但真实业务里很多“写少”场景其实是错觉——比如日志表看似只写不读，但若加了 created_at、user_id、status 三个单列索引，每次插入就要维护三棵独立 B+ 树。
- 复合索引能覆盖的查询，别用多个单列索引堆砌
-
TEXT或VARCHAR(500)字段慎建索引，除非明确用了前缀长度（如INDEX idx_content (content(100))） - 唯一性很低的字段（如
gender、is_deleted）单独建索引几乎无效，优化器通常会直接全表扫描
索引占用磁盘和内存资源
每个索引都是独立的物理文件（InnoDB 下存于 .ibd），且会加载进 innodb_buffer_pool。一个 10GB 的表，如果索引总大小达到 6GB，意味着缓冲池一半以上在服务索引而非数据页，反而挤占热数据缓存空间。
更隐蔽的问题是：索引越多，统计信息越复杂，ANALYZE TABLE 耗时越长，而 MySQL 依赖这些统计信息生成执行计划。某些版本下，索引数超 20 个，EXPLAIN 的 key_len 和 rows 估算可能明显失真。
- 用
SELECT table_name, index_name, seq_in_index, column_name FROM information_schema.statistics WHERE table_schema = 'your_db' AND table_name = 'your_table';查看索引列顺序和冗余情况 - 通过
SHOW INDEX FROM your_table;观察Cardinality值，接近 0 或远小于表行数的索引大概率低效 - 删除索引前先查
performance_schema.table_io_waits_summary_by_index_usage（MySQL 8.0+），确认该索引是否被任何查询使用过
优化器可能选错执行计划
索引不是越多越好，而是越精准越有用。当存在多个可选索引时，MySQL 优化器基于成本模型决策，但这个模型对并发、缓存状态、数据分布并不敏感。例如 WHERE a = ? AND b = ? ORDER BY c，如果有 (a)、(b, c)、(a, b, c) 三个索引，优化器有时会错误选择 (b, c)，导致 Using filesort 或临时表。
这种问题在 JOIN 多表、WHERE 条件动态拼接的场景下尤其明显。一旦执行计划固化（如用了 SQL_NO_CACHE 或预编译语句未重准备），坏索引的影响会长期存在。
- 用
EXPLAIN FORMAT=JSON看used_columns和possible_keys，比普通EXPLAIN更清楚优化器取舍逻辑 - 避免在同一个字段上建功能重复的索引，比如既有
INDEX idx_status (status)，又有INDEX idx_status_time (status, created_at)，前者基本无存在必要 - 对高频查询，宁可用
FORCE INDEX显式指定，也不要靠堆索引让优化器“猜”
维护成本随索引数量非线性上升
线上 DDL 变更（比如加字段、改类型）在有大量索引的表上可能卡住几小时，因为 MySQL 5.7+ 虽支持 ALGORITHM=INPLACE，但多数索引操作仍需重建全部索引。备份恢复时，mysqldump 导出的 CREATE INDEX 语句默认串行执行，索引越多耗时越长；而物理备份（如 XtraBackup）虽快，但恢复后首次启动仍要校验所有索引一致性。
另一个容易被忽略的点：主从复制延迟。主库写入触发多个索引更新，从库 SQL 线程单线程回放这些变更，索引多的表更容易成为复制瓶颈。
- 定期跑
pt-duplicate-key-checker（Percona Toolkit）识别重复或冗余索引 - 对大表删索引，优先用
ALTER TABLE ... DROP INDEX而非重建表，减少锁表时间 - 监控
information_schema.INNODB_METRICS中的index_page_splits和index_page_reorgs，异常升高往往意味着索引设计不合理
SHOW INDEX 结果里，直到某次大促时突然把缓冲池和磁盘 IO 同时压垮。 
