为什么MySQL单表索引数量建议不要超过5个？-mysql教程-PHP中文网

索引会显著拖慢insert/update/delete操作，因每增一个索引，写入时就要多执行一次b+树维护（含页分裂、指针调整、唯一性校验等），5个索引即1次主键写入+5次索引插入，导致耗时跃升、锁等待增多、解析开销加大，并占用大量磁盘与内存资源。

为什么mysql单表索引数量建议不要超过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 倍。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

查索引空间开销的可靠方式是：

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 占比、以及它不可被其他索引替代的理由。否则，它大概率只是在默默拖慢你的写入、吃掉你的磁盘、干扰优化器判断。