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