控制 MySQL 索引数量的核心是避免“为索引而索引”，只保留被查询驱动、性能提升显著且维护成本可控的索引；需依慢查询日志和 EXPLAIN 分析高频 SQL，优先建联合索引，清理冗余失效索引，单表建议≤5–7 个，并通过工具审核与覆盖索引优化。
控制 MySQL 索引数量的核心，是避免“为索引而索引”，只保留真正被查询驱动、能显著提升性能且维护成本可控的索引。
按查询需求建索引，不凭感觉
索引不是越多越好，每个新增索引都会拖慢 INSERT/UPDATE/DELETE，并占用磁盘和内存。先通过慢查询日志（slow query log）或 EXPLAIN 分析高频 SQL，确认 WHERE、JOIN、ORDER BY、GROUP BY 中实际参与过滤或排序的字段组合。例如：
- 如果常查
WHERE status = ? AND created_at > ?，优先考虑联合索引(status, created_at)，而非单独给两个字段建索引； - 单列索引
(a)和联合索引(a, b)同时存在时，(a)很可能冗余，可删除。
定期识别并清理冗余和失效索引
使用系统视图定位低效索引：
- 查未被使用的索引：
SELECT * FROM sys.schema_unused_indexes;（需开启 performance_schema）； - 查重复或前缀覆盖的索引：比如已有
(user_id, order_time)，再建(user_id)就是冗余； - 注意 隐式类型转换 导致索引失效（如字符串字段用数字查询），这类索引虽存在但实际不生效，应修正查询写法而非保留索引。
限制单表索引总数，设定硬性阈值
建议单表索引数不超过 5–7 个（含主键）。超限时必须走评审流程，明确每个索引的查询场景、QPS 影响、写入衰减预估。可通过以下方式落地管控：
- 在 DDL 审核平台（如 SOAR、Archery）中配置规则，自动拦截新增索引超过阈值的工单；
- 开发阶段用 pt-duplicate-key-checker 扫描测试库，提前发现重复索引；
- 上线前执行
SHOW INDEX FROM table_name对照清单复核。
用覆盖索引减少回表，替代盲目加字段
当查询只需返回少量字段，可将 SELECT 列也加入索引末尾，形成覆盖索引，避免回主键查找。例如：
- 查询
SELECT id, name FROM users WHERE email = ?，建索引(email, name)比只建(email)更高效； - 但不要把大字段（如 TEXT、JSON）加入索引——会显著增大索引体积，得不偿失。
索引维护不是一劳永逸的事。随着业务迭代，旧索引会失效，新查询会冒头。把索引当作代码一样版本化管理，结合监控（如 innodb_rows_read 与 innodb_rows_updated 的比值趋势）、定期巡检和团队共识，才能让索引始终精简有力。
