MySQL慢查询日志默认关闭，需手动启用；开启后须确保日志格式合规、路径正确，并用mysqldumpslow结合-s t/-s l等参数分析真实瓶颈，再通过EXPLAIN验证执行计划是否一致。
MySQL 慢查询日志默认是关闭的，不手动开就永远没记录
MySQL 启动时不会自动启用慢查询日志，哪怕你改了配置文件，没重启或没动态生效，
依然是
。最直接的验证方式是执行：
如果返回
，那后续所有分析都白搭。
开启方法有两种，优先用动态方式（不用重启）：
- 设置日志开关：
- 指定阈值（例如超过 1 秒算慢）：
- 指定日志路径（需 MySQL 进程有写权限）：
⚠️ 注意：
是浮点数，设成
会记录所有查询（含
），线上慎用；设成
但实际语句耗时
秒也不会记——它只看秒级精度截断后的值（5.7+ 可设更细，但需确认版本）。
mysql
dum
ps
low 解析前必须确保日志格式合规
只认 MySQL 原生日志格式，如果日志里混了非标准内容（比如被其他脚本追加了时间戳、注释、或启用了
写进
表），它会直接报错或解析出空结果。
检查日志头是否合规：
正常开头应类似：
和
。如果不是，说明日志没走标准路径，或被重定向/轮转污染。
常见干扰项：
-
：会导致部分日志写表、部分写文件，
只读文件，漏掉大量慢查
- 日志被
切割后没通知 MySQL reopen，新日志仍写旧文件描述符（看似有内容，实则丢失）
- 应用层代理（如 ProxySQL）记录的“慢”不是 MySQL 真实执行耗时，不能拿去喂
用 mysqldumpslow 看 top SQL 时别只盯 count，要看 avg_lock_time 和 Rows_examined
默认按出现次数排序（
），但高频 ≠ 高危。一条每秒跑 100 次、每次锁表 200ms 的
，比一天只跑一次但耗时 30 秒的
更伤系统。
稿定在线PS
PS软件网页版
下载
关键参数组合：
-
：按总耗时排 top 10（
）
-
：按平均锁等待时间排（
），揪出锁争用元凶
- 加
显示完整语句（避免参数被
替换掩盖真实模式）
- 加
可过滤关键词，但注意大小写敏感且不支持正则
输出中重点关注：
（扫描行数）远大于
（返回行数）？大概率缺索引；
高但
低？可能是 MVCC 版本链过长或锁冲突。
分析完慢查，下一步不是优化 SQL，而是确认执行计划是否真变了
从慢日志里复制出的 SQL，直接在生产库
可能和日志里执行时的计划完全不同：表统计信息更新了、索引被删了、甚至 SQL 被客户端重写了（如 ORM 自动加
）。
稳妥做法：
- 用
提取最慢的一条，带上
和
信息
- 查对应时间点的
或 Performance Schema（如果开了）确认当时实际执行计划
- 在同库同表数据量相近的备库上复现，再
看细节
- 特别留意
是
还是
，
是否为
，
是否低于 10%
很多“优化后还是慢”的问题，根源是分析用的 SQL 和日志里那条看着像、实际执行路径已偏移——日志记录的是快照，不是回放录像。
slow_query_logOFFSHOW VARIABLES LIKE 'slow_query_log';OFFSET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 1.0;SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';long_query_time0SELECT 110.999mysqldumpslowlog_output = TABLEmysql.slow_loghead -n 5 /var/log/mysql/mysql-slow.log# Time: 2024-06-12T08:23:45.123456# User@Host:log_output = FILE, TABLEmysqldumpslowlogrotatemysqldumpslowmysqldumpslow-s cUPDATESELECTmysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log-s tmysqldumpslow -s l -t 10 ...-s l-a?-g "WHERE user_id"Rows_examinedRows_sentLock_timeQuery_timeEXPLAINLIMIT 1mysqldumpslow -s t -t 1 ...TimeUser@HostSHOW PROFILESEXPLAIN FORMAT=JSONtypeALLrangekeyNULLfiltered