MySQL 索引优化：从慢查询到可解释的执行计划

打开 「slow_query_log」 之后，真正有价值的是把每条慢 SQL 和 「EXPLAIN」 对上号。

先看执行计划里的信号

• 「type=ALL」：全表扫，优先怀疑缺索引或条件无法用索引
• 「key」 为空：优化器没用上你以为存在的索引
• 「rows」 很大且 「Extra」 有 「Using filesort」 / 「Using temporary」：排序与分组成本高

常见误区

1. 在列上包函数：「WHERE DATE(created_at) = ...」 会破坏索引，改成范围条件。
2. 左右模糊：「LIKE '%foo'」 无法走 BTree 前缀；需要换方案或冗余检索字段。
3. 选择性极低的列单独索引：如 「status」 只有两三个值，往往要和业务高频列组成联合索引。
4. 过度索引：写入变慢、优化器更难选对；先覆盖真正的慢查询。

联合索引顺序

遵循「等值 → 范围 → 排序」的经验顺序，并与最常见的 「WHERE」 + 「ORDER BY」 对齐。例如文章列表：

-- 适合：status = ? ORDER BY published_at DESC
INDEX(status, published_at)

验证方式

改索引后用同一条 SQL 对比 「EXPLAIN」 与实际耗时；有条件上线前在从库或备份实例验证。

小结

索引是「查询形状」的镜像。先固定业务查询，再设计索引，而不是反过来。