MySQL慢查询日志需开启slow_query_log=ON、long_query_time=1.0、log_slow_admin_statements=ON，并指定绝对路径的slow_query_log_file；pt-query-digest解析时须用原生日志格式，配合--limit、--filter、--report-format profile等参数精准定位真实瓶颈。
慢查询日志怎么开，开哪些参数才有效
MySQL 默认不记录慢查询，必须手动开启并调优参数，否则 pt-query-digest 拿不到真实瓶颈 SQL。
-
slow_query_log = ON是开关，必须设为ON（不是1，某些旧版本兼容但新版本建议用字符串） -
long_query_time = 1.0建议从1.0开始，太低（如0.1）会导致日志爆炸，太高（如5.0）会漏掉批量更新、关联多表等“温吞型”慢 SQL -
log_queries_not_using_indexes = OFF建议关掉，它会把没走索引但执行很快的简单查询也记进来，干扰 Top 分析 -
slow_query_log_file必须指定绝对路径，且确保 MySQL 进程有写权限，常见坑是写到/var/log/mysql/下却因 SELinux 或权限被拒
线上环境建议搭配 log_slow_admin_statements = ON，否则 ALTER TABLE、ANALYZE TABLE 这类管理语句不会进慢日志，而它们恰恰常是锁表元凶。
pt-query-digest 怎么解析，关键参数别写错
pt-query-digest 不是“跑一下就出 Top10”，参数选错等于白跑。最常用也最容易翻车的是输入源和聚合逻辑。
- 输入必须是 MySQL 原生慢查询日志格式（不是 general log，也不是 JSON 或慢 SQL 截图），命令形如：
pt-query-digest /var/log/mysql/mysql-slow.log
- 加
--limit 10控制输出行数，但注意：这是按“查询指纹”聚合后的排序，不是原始日志行数 -
--filter可过滤干扰项，例如排除监控探活 SQL：--filter '$event->{fingerprint} !~ m/^SELECT NOW|SELECT UNIX_TIMESTAMP/i' - 如果日志量大（>1GB），务必加
--no-report先试跑，避免内存爆掉；真正分析时用--report-format profile看各阶段耗时占比（parse、exec、lock 等）
别直接用 --review 往 DSN 写入，第一次跑建议先 --print 看几条典型指纹，确认是否真聚合了你关心的业务 SQL（比如 SELECT * FROM order WHERE user_id = ? AND status = ? 被归为一类，而不是拆成几百个带不同值的变体）。
为什么同一个 SQL 在报告里排不高，但应用就是卡
pt-query-digest 默认按总响应时间（Query_time）排序，但实际卡顿往往来自并发等待，而非单次执行长。
- 单次
Query_time = 0.02s的 SQL，如果每秒执行 500 次、且都争抢同一行锁，pt-query-digest会把它排在很后面，但应用线程大量卡在Waiting for table metadata lock或Locked - 此时要看报告里的
Lock_time和Rows_examined：高Rows_examined+ 低Rows_sent说明扫描浪费严重；高Lock_time占比（比如 >60%）提示锁竞争是瓶颈 - 更关键的是打开
performance_schema，查events_statements_summary_by_digest，它能统计等待事件（wait/io/table/sql/handler）、内存分配、临时表使用——这些slow log根本不记录
一个典型陷阱：ORM 自动生成的 SELECT COUNT(*) FROM ... 分页统计，Query_time 可能只有 0.1s，但 Rows_examined 高达百万，且无法走覆盖索引，这类 SQL 在 pt-query-digest 里未必进 Top，却是数据库 CPU 和 IO 的隐形杀手。
线上抓取窗口和采样策略怎么定
不能等用户投诉了再翻日志，也不能无休止全量收集。
- 日志轮转必须配
log_rotation或用logrotate，否则单个mysql-slow.log超过 2GB 后pt-query-digest解析极慢，且易 OOM - 建议按小时切分日志（
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow-20240501-14.log），再用pt-query-digest聚合当天所有小时文件 - 对高流量库，可临时开启
long_query_time = 0.5并只保留最近 2 小时日志；对低频核心库，long_query_time = 2.0+ 保留 24 小时更稳妥 - 如果用代理层（如 ProxySQL、MaxScale），优先在代理侧开启慢日志，它能记录客户端真实 IP 和应用名，比 MySQL 原生日志更容易定位到具体服务模块
最常被忽略的一点：pt-query-digest 输出的 “%Total” 是基于当前日志样本的相对值，不是绝对负载占比。如果只抓了凌晨低峰期 10 分钟日志，Top SQL 很可能是定时任务，不代表白天的瓶颈；务必核对日志时间戳范围，和业务高峰期对齐。
