【MySQL】SQL性能分析

SQl语句的优化一般是优化select语句。

下面介绍几种性能分析工具

1、命令执行频次

--展示全局命令执行频次

show global status like 'com_______';

2、慢查询日志

查看慢查询日志启用情况

show variables like 'slow_query_log';

在/etc/my.cnf中修改慢查询日志参数

show_query_log=1   --启用慢查询日志

long_query_time=2   --慢查询判定值，单位为秒

修改完成后执行

systemctl restart mysqld

查看慢查询日志

tail -f localhost-show.log;

3、SQL耗时情况

检查是否开启该工具

show @@having_profiling;

开启

set profiling=1;

命令

show profiles; --查看所有记录的查询列表

show profiles for query 16;  --精准定位某句SQL的查询瓶颈

4、查询执行计划

explain 查询命令

执行计划各字段意义（列举几个重点关注字段）

select_type（查询类型）：说明查询的复杂度

值​​	​​含义​​
SIMPLE	简单查询（无子查询或 UNION）
PRIMARY	最外层查询
SUBQUERY	子查询中的第一个 SELECT
DERIVED	派生表（如 FROM子句中的子查询）
UNION	UNION中的第二个或后续查询
UNION RESULT	UNION的结果集

type：描述表如何被访问（性能从优到劣排序）：

​​访问类型​​	​​性能​​	​​场景​​
system	★★★★★	表只有一行（系统表）
const	★★★★★	通过主键/唯一索引查到单行（WHERE id = 1）
eq_ref	★★★★☆	联表时使用主键/唯一索引匹配（A.id = B.id）
ref	★★★☆☆	使用非唯一索引查找（WHERE name = 'Alice'）
range	★★☆☆☆	索引范围扫描（WHERE age > 18）
index	★☆☆☆☆	全索引扫描（比全表快，但需避免）
ALL	✘	全表扫描（需紧急优化！）

possible_keys（可能使用的索引）​

key（实际使用的索引 ★★★）

key_len（索引长度）​：使用的索引字节数（用于判断​​复合索引是否充分利用​​）。

rows（预估扫描行数 ★★★）：值越大性能越差，若远超实际数据量，需优化索引或查询条件。

索引的最左前缀原则

假设我们有一个 users表和一个复合索引 idx_name_age_city (name, age, city)。

查询条件	是否使用索引？	解释
WHERE name = 'Alice'	​​✅ 使用​​	使用了索引的最左列 name。
WHERE name = 'Alice' AND age = 30	​​✅ 使用​​	连续使用了索引的前两列 name和 age。
WHERE name = 'Alice' AND age = 30 AND city = 'SF'	​​✅ 使用​​	完美使用了所有三列。
WHERE age = 30 AND city = 'SF'	​​❌ 未使用​​	​​缺少最左列 name​​。没有 name，age和 city在索引整体上是无序的，所以无法高效使用索引。
WHERE name = 'Alice' AND city = 'SF'	​​✅ 部分使用​​	使用了索引的 name列，但因为跳过了中间的 age列，无法使用 city列进行​​索引过滤​​（但可能用于覆盖查询）。
WHERE name = 'Alice' AND age > 25 AND city = 'SF'	​​✅ 部分使用​​	使用了 name和 age列。但在 age列进行了范围查询后，city在结果集里是无序的，因此​​索引无法用于过滤 city​​。
WHERE name LIKE 'A%' AND age = 30	​​✅ 部分使用​​	使用了 name列（最左前缀）。虽然 LIKE是范围查询，但以通配符开头（%）才会终止匹配，LIKE 'A%'仍然可以走索引。但 age可能无法用于高效过滤。