如何确认 MySQL 慢查询日志是否真正启用
很多情况下你以为开启了慢查询日志，但
slow_query_log变量显示
ON，实际日志文件却为空——根本原因是
long_query_time设置过高（比如默认 10 秒），而你的业务里几乎没有执行超 10 秒的语句。
检查和修正步骤：
用SHOW VARIABLES LIKE 'slow_query_log%';确认
slow_query_log和
slow_query_log_file的值 运行
SELECT @@long_query_time;，生产环境建议设为
1.0或更低（注意：MySQL 5.7+ 支持毫秒级，如
0.5） 动态生效需执行
SET GLOBAL long_query_time = 0.5;（注意：该命令对已连接会话不生效） 务必在
my.cnf中补全配置，避免重启后失效：
[mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 0.5 log_queries_not_using_indexes = OFF
log_queries_not_using_indexes = ON虽能暴露缺失索引的查询，但日志量爆炸，上线前务必关掉。
用 mysqldumpslow 快速定位高频/高耗时 SQL
mysqldumpslow是 MySQL 自带的解析工具，比手动
grep或写脚本更可靠——它能自动归一化 SQL（比如把
WHERE id = 123和
WHERE id = 456合并为
WHERE id = ?）。
常用组合命令：
按执行次数排序，看谁调用最频繁：mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log按平均查询时间排序，找“单次最慢”的语句：
mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log只看扫描行数超过 1000 的：
mysqldumpslow -m 1000 -t 10 /var/log/mysql/mysql-slow.log
注意：
-s at是平均时间（average time），不是最大时间；
-m参数仅在 MySQL 8.0.22+ 支持，低版本需靠
awk过滤
Rows_examined字段。
EXPLAIN 结果里最关键的三列怎么看
拿到慢 SQL 后，不要急着加索引。先跑
EXPLAIN FORMAT=TRADITIONAL，盯住这三列：
type：必须至少到
range，
ALL或
index表示全表/全索引扫描，危险信号
key：显示实际命中哪个索引。若为
NULL，说明没走索引（可能因隐式类型转换、函数包裹字段、或
OR条件破坏索引选择）
rows：预估扫描行数。若远大于结果集行数（比如
SELECT COUNT(*)返回 100 行，但
rows=50000），说明索引区分度差或没覆盖查询条件
典型陷阱：
ORDER BY字段不在索引中，即使
WHERE走了索引，也可能触发
Using filesort；
GROUP BY后跟
HAVING且无对应索引，同样会导致临时表 + 排序。
优化时优先考虑覆盖索引而非单纯提速 WHERE
很多同学看到
WHERE a = ? AND b = ?慢，就建
(a,b)索引。但如果查询还带
SELECT c, d，而
c,d不在索引里，MySQL 仍要回表查聚簇索引——IO 成本没省多少。
正确做法是构建覆盖索引：
ALTER TABLE orders ADD INDEX idx_user_status_created (user_id, status, created_at);
这样当执行
SELECT status, created_at FROM orders WHERE user_id = 123时，
Extra字段会显示
Using index，全程只访问二级索引，不碰主键 B+ 树。
但注意：覆盖索引字段越多，索引体积越大，写入开销上升。别把所有
SELECT *字段都塞进去；也别在
TEXT或长
VARCHAR列上建覆盖索引（会触发前缀索引截断，降低准确性）。
