MySQL索引优化核心是建得准而非建得多，需遵循最左匹配原则、选择高区分度字段作前导列，并避免函数操作导致索引失效。

MySQL索引优化的核心是让查询尽可能走索引、减少扫描行数、避免回表和失效场景。关键不在于建得多，而在于建得准。

选择高区分度的列作为索引前导列

索引生效依赖最左匹配原则。如果联合索引是 (status, create_time, user_id)，那 WHERE status = 1 AND create_time > '2025-01-01' 能用上前两列；但 WHERE create_time > '2025-01-01' 就完全用不上这个索引。

• 优先把查询中 过滤性最强（值分布最散） 的字段放在联合索引最左边，比如 order_no（唯一）比 status（常见 0/1/2）更适合做首列
• 避免在索引列上做函数操作或隐式类型转换，如 WHERE DATE(create_time) = '2025-01-01' 会让索引失效，应改写为 WHERE create_time >= '2025-01-01' AND create_time

覆盖索引减少回表开销

当 SELECT 的字段全部包含在索引中，MySQL 就不用回到主键索引再查数据行，这种叫“覆盖索引”，能显著提升性能。

• 例如常查 SELECT user_id, status, update_time FROM orders WHERE status = 1 ORDER BY update_time DESC，可建联合索引 (status, update_time, user_id) —— 三个字段都涵盖，无需回表
• 注意：SELECT * 很难被覆盖，应明确列出需要的字段

精简索引数量，定期清理冗余索引

每个索引都会增加写入成本（INSERT/UPDATE/DELETE 都要维护索引），且可能相互干扰。MySQL 不会自动识别重复或包含关系的索引。

• 用 SELECT * FROM sys.schema_redundant_indexes;（需启用 sys schema）或 pt-duplicate-key-checker 工具识别冗余索引
• 例如已有 (a, b, c)，再建 (a, b) 就是冗余；已有 (a) 和 (a, b)，单独的 (a) 通常可删
• 对低频更新、高频查询的表可适度增加索引；对日志类写多读少的表，索引宜保守

利用执行计划验证索引是否生效

别猜，要看 EXPLAIN 结果。重点关注 type、key、rows、Extra 这几列。

• type 最好是 const、ref、range；ALL 表示全表扫描，危险信号
• key 显示实际使用的索引名；NULL 表示没走索引
• rows 是预估扫描行数，越小越好；若远大于结果集行数，说明索引选择不佳或统计信息过期（可用 ANALYZE TABLE 更新）
• Extra 中出现 Using filesort 或 Using temporary 说明排序/分组未走索引，需检查是否缺失排序字段索引