MySQL索引与Explain速查

相关概念：MySQL

排查 MySQL 查询性能时，最值得反复回看的通常不是某条“神奇 SQL”，而是索引规则和 EXPLAIN 的基本判断。

先抓入口

查看执行频次

SHOW GLOBAL STATUS LIKE 'Com_______';

查看是否开启慢查询

SHOW VARIABLES LIKE 'slow_query_log';

最常用的执行计划

EXPLAIN SELECT ...

EXPLAIN 里优先看什么

• type：性能层级最重要，越接近 const / ref 越好，all 往往意味着全表扫描
• key：实际使用的索引
• rows：MySQL 预估要扫描的行数
• filtered：过滤比例，通常越高越好

索引设计的几个硬规则

• 联合索引尽量遵守最左前缀
• 常参与 where / order by / group by 的列优先考虑索引
• 优先关注区分度高的列
• 多字段查询里，联合索引通常比堆很多单列索引更有效
• 索引不是越多越好，写入和维护成本都要算进去

常见索引失效场景

• 联合索引中间列被跳过
• 索引列上套函数
• 字符串比较时类型不匹配
• 左模糊查询
• or 两边只有一侧可用索引
• 优化器判断走索引还不如全表扫

两个很实用的技巧

覆盖索引

如果查询字段都已经包含在索引里，可以避免回表。

前缀索引

对于长字符串列，可以只索引前缀：

CREATE INDEX idx_xxx ON tablename(columnname(10));

它的核心取舍是：节省索引空间，但要关注区分度是否够用。

一个经验判断

调优时不要一上来就迷信“换写法”。先确认：

• 有没有合适索引
• 执行计划到底走了什么
• 查询慢是扫描太多，还是排序、回表、临时表太多