索引并非越多越好，需权衡查询加速收益与维护成本；过多索引会降低写入性能、增加存储开销、干扰优化器选型并加剧缓存压力。
索引数量不是越多越好，而是要权衡查询加速收益与维护成本之间的关系。过多的索引会拖慢写入性能、占用更多磁盘空间，并可能干扰优化器选择最优执行计划。
索引带来的主要成本
每增加一个索引，都会在数据变更（INSERT/UPDATE/DELETE）时触发额外的维护操作：
- 写入变慢：每次插入一行，不仅写主表（聚簇索引），还要更新所有相关二级索引；更新或删除时同理，索引越多，I/O 和 CPU 开销越大。
- 存储膨胀：索引本身需要存储空间，尤其对大字段（如 VARCHAR(1000)、TEXT）建索引，或复合索引列数过多时，空间开销显著上升。
- 优化器决策负担加重：MySQL 或 PostgreSQL 的查询优化器需评估多个索引路径，索引过多可能导致选错执行计划，反而降低查询效率。
- 缓存压力增大：索引页也会进入缓冲池（如 InnoDB Buffer Pool），过多低效索引会挤占真正热数据的缓存空间。
什么情况下索引可能“多余”？
以下几类索引常被误建，实际价值很低：
- 单列低选择性字段索引：例如 gender（只有 'M'/'F'）、status（0/1/2），区分度太低，全表扫描往往比走索引更快。
- 前缀重复率高的复合索引：如 INDEX(a, b, c)，但查询只用 WHERE a = ?，而 a 值分布极不均匀（90% 是同一值），该索引利用率低。
- 被覆盖索引替代的单列索引：已有 INDEX(a, b)，再单独建 INDEX(a) 属于冗余——前者已能支撑 a 上的等值查询。
- 长期未被使用的索引：可通过 performance_schema.table_io_waits_summary_by_index_usage（MySQL 8.0+）或 pg_stat_all_indexes（PostgreSQL）识别零使用索引。
如何科学控制索引数量？
核心思路是“按需建设、定期审视、合并优先”：
- 先看慢查，再建索引：通过慢查询日志 + EXPLAIN 分析，确认 WHERE、JOIN、ORDER BY、GROUP BY 中的实际过滤/排序字段，避免凭经验预建。
- 优先考虑覆盖索引：把 SELECT 字段也纳入索引列（放在最后），避免回表，一个索引解决多个需求。
- 合并相似索引：比如已有 INDEX(user_id, created_at)，又新增 INDEX(user_id, created_at, status)，可考虑扩展为三列索引，而非并存。
- 设置索引生命周期意识：业务迭代后，旧查询下线，对应索引应及时清理；新表上线初期可保留观察期（如1–2周），再根据真实访问模式精简。
索引是典型的“双刃剑”，设计目标不是消灭全表扫描，而是让关键路径足够快，同时不让写入和运维成本失控。不复杂但容易忽略。
