怎么确认慢查询日志真正在记录？
很多问题其实卡在第一步：你以为日志开了，其实没生效。最直接的验证方式是手动触发一条超时查询，再检查日志是否落盘。
先查状态：SHOW VARIABLES LIKE 'slow_query_log'—— 必须返回
ON，不是
OFF或空值 再看阈值：
SHOW VARIABLES LIKE 'long_query_time'—— 默认是
10秒，生产环境建议调成
2或
1；注意：该值支持小数（如
0.5），但仅对 MySQL 5.1+ 有效 执行一条“人造慢SQL”：
SELECT SLEEP(3)，然后立刻检查日志文件路径：
SHOW VARIABLES LIKE 'slow_query_log_file'用
sudo tail -n 20 /var/log/mysql/mysql-slow.log看是否新增了含
# Time:和
# Query_time:的块 —— 没有就说明配置未生效或路径权限不对（常见于 SELinux 或 systemd-journald 截断日志）
用 mysqldumpslow 快速定位高频/高耗时 SQL
mysqldumpslow是 MySQL 自带的轻量工具，适合快速筛出“最该优先处理”的语句，不依赖额外安装。 按总耗时排序前 10 条：
mysqldumpslow -t 10 -s t /var/log/mysql/mysql-slow.log（
-s t表示按
Query_time总和排序） 按执行次数排序，看“反复出现但单次不慢”的隐患：
mysqldumpslow -t 10 -s c /var/log/mysql/mysql-slow.log（
-s c= count） 加
-g过滤关键词，比如只看涉及
order的慢查询：
mysqldumpslow -g "ORDER BY" /var/log/mysql/mysql-slow.log⚠️ 注意：
mysqldumpslow会自动忽略大小写、合并参数占位符（如把
WHERE id=123和
WHERE id=456视为同一条），所以它统计的是“模板级”频次，不是原始语句 —— 别拿它做审计溯源
用 pt-query-digest 做深度归因分析
当
mysqldumpslow给出线索后，真正要定位瓶颈，得靠
pt-query-digest。它能解析执行计划、锁等待、扫描行数等隐藏信息，且输出可读性远高于原始日志。 安装 Percona Toolkit：
apt install percona-toolkit（Debian/Ubuntu）或
yum install percona-toolkit（RHEL/CentOS） 生成结构化报告：
pt-query-digest /var/log/mysql/mysql-slow.log > slow-report.txt重点关注报告里的 “Profile” 表格：看哪类查询占用了最多响应时间（
Response time列），以及 “Rank” 排名靠前的语句中
Rows_examined是否远大于
Rows_sent（典型全表扫描信号） 报告末尾的 “Query 1” 会附带原始 SQL +
EXPLAIN模拟结果 + 建议索引（如
ADD INDEX ...），但别盲目照搬 —— 要结合实际 WHERE 条件和数据分布判断
为什么 EXPLAIN 结果里 rows 很大，却没走索引？
这是最常被误判的环节。看到
rows: 120000就以为“加个索引就行”，但往往忽略了索引是否真的能覆盖查询条件。 检查
type字段：如果是
ALL（全表扫描）或
index（全索引扫描），基本确认没走有效索引 看
key字段是否为空 —— 为空即未命中任何索引；若非空但
rows仍很大，可能是索引选择性差（如对性别字段建索引） 留意
Extra字段：
Using filesort或
Using temporary表示排序/分组无法利用索引完成，需考虑联合索引覆盖
ORDER BY或
GROUP BY字段 一个典型陷阱：
WHERE status='active' AND created_at > '2025-01-01'，只给
status建单列索引无效，必须建联合索引
(status, created_at)，且字段顺序不能颠倒
真实线上慢查询往往不是单点问题，而是索引缺失、隐式类型转换、OR 条件滥用、分页偏移过大等多个因素叠加。最危险的是“日志里没报，但业务已卡顿”——因为
long_query_time只统计执行时间，不统计锁等待、网络延迟或连接池排队。所以别只盯日志，要把
SHOW PROCESSLIST、
information_schema.INNODB_TRX和应用层监控一起看。
