数据库表存在「过度索引」吗？MySQL新表何时建查询索引更合适？

嘿，这个问题问到点子上了——不少刚着手MySQL表设计的开发者都会在索引的时机和“度”上犯难，咱们掰开揉碎了说：

1. 确实存在“过度索引”的现象 #

过度索引不是玄学，是实实在在会影响性能的问题：

• 写操作开销陡增：每次执行INSERT/UPDATE/DELETE时，MySQL不仅要修改表数据，还要同步更新所有相关索引。索引越多，这个维护成本就越高——小表阶段可能没感觉，但数据量上来后（比如十万+级别），每次写操作的耗时会明显增加。
• 浪费存储空间：每个索引都是独立的数据结构，过多不必要的索引会占用额外的磁盘空间，尤其是对于大表来说，这点会更突出。
• 干扰优化器决策：MySQL优化器会在多个索引中选择最优执行计划，如果索引太多，优化器可能会选错索引（比如选了一个低效的单列索引，而不是更合适的联合索引），反而拖慢查询速度。

2. 初始阶段给WHERE列加索引，会不会有性能损耗？ #

分情况看，但大部分场景下可以忽略：

• 如果你的表是小表（几千到几万条数据），即使给几个WHERE列加索引，写操作的额外开销几乎感受不到——毕竟数据量小，维护索引的成本极低。
• 但如果盲目给所有WHERE列都单独加索引（比如明明可以用联合索引覆盖的场景，却建了N个单列索引），或者你的表从一开始就有极高频率的写操作，那可能会有轻微的性能影响，但这种情况在开发阶段一般可以接受，后期再调整也来得及。

3. 到底该什么时候创建索引？ #

不要等表到一定规模再补索引，而是从设计阶段就合理规划，原因很简单：

• 等表变大（比如百万级以上）再加索引，即使是InnoDB的在线DDL，也会占用大量IO和CPU资源，甚至短时间锁表，影响线上业务的正常运行。
• 正确的做法是：
  • 先梳理业务中的高频查询模式，只给真正用于WHERE过滤、JOIN关联、ORDER BY排序的列加索引，不要为了“以防万一”加一堆没用的索引。
  • 优先考虑联合索引而非多个单列索引：比如如果你的查询常是WHERE a=? AND b=?，建(a,b)的联合索引比单独建a和b的索引更高效，还能减少索引数量。
  • 开发阶段先加上必要的索引，后续通过EXPLAIN分析慢查询日志，再逐步优化：删掉从未被使用的索引，补充缺失的必要索引。

总结一下：不用刻意等表变大再加索引，但一定要避免过度索引——只加业务真正需要的索引，优先用联合索引精简数量，从设计阶段就打好基础，后期再根据实际查询情况迭代优化。

内容的提问来源于stack exchange，提问作者Noel Llevares