<p>先执行SHOW VARIABLES LIKE 'slow_query_log'确认为ON，再用SELECT SLEEP(3)触发慢查询并检查slow_query_log_file路径下日志是否新增含# Time:和# Query_time:的记录。</p>
怎么确认慢查询日志真正在记录？
很多问题其实卡在第一步：你以为日志开了，其实没生效。最直接的验证方式是手动触发一条超时查询，再检查日志是否落盘。
- 先查状态：
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 和应用层监控一起看。
