控制 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的比值趋势）、定期巡检和团队共识，才能让索引始终精简有力。
