索引太多会导致写入变慢
每新增一条记录，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 同时压垮。
