如何确认慢查询日志已开启并定位日志路径
MySQL 默认不开启慢查询日志，必须手动配置生效。先检查当前状态：
SHOW VARIABLES LIKE 'slow_query_log'，返回
OFF就说明没开；再看日志路径：
SHOW VARIABLES LIKE 'slow_query_log_file'，常见默认值是
/var/lib/mysql/hostname-slow.log，但实际路径依赖
my.cnf中的
slow_query_log_file配置项。
开启需在配置文件中设置：
slow_query_log = ON slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 1.0
注意：
long_query_time是浮点数（单位秒），设为
0会记录所有查询（慎用，IO 压力大）；5.7+ 版本还支持
log_queries_not_using_indexes，但开启后可能误报（如小表全表扫描合理）。
用 mysqldumpslow 快速提取高频慢查询模式
mysqldumpslow是 MySQL 自带的轻量分析工具，适合初步归类和排序。它不解析 SQL 语义，而是按“模式”聚合（比如把
WHERE id = 123和
WHERE id = 456归为同一类）。
常用组合：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log：按总执行时间降序取前 10 条模式
mysqldumpslow -s c -t 5 /var/log/mysql/mysql-slow.log：按出现次数排序，找高频低效语句
mysqldumpslow -g "SELECT.*FROM orders" /var/log/mysql/mysql-slow.log：过滤含关键词的慢查询
缺点明显：无法识别参数化差异大的语句（如不同 IN 列表长度）、不支持 JSON 格式输出、不能关联表结构或执行计划。遇到复杂场景就得上
pt-query-digest。
用 pt-query-digest 深度分析并生成可操作建议
pt-query-digest（Percona Toolkit）是事实标准，能解析慢日志、统计资源消耗、匹配索引缺失、甚至模拟 EXPLAIN。它把每条查询抽象成
Query ID，自动去重归类，并给出
EXPLAIN建议。
基础用法：
pt-query-digest /var/log/mysql/mysql-slow.log --limit 10
关键能力点：
自动标注full scan、
no index、
Using temporary; Using filesort等性能风险标签 支持
--review把分析结果存入 MySQL 表，方便比对历史趋势 加
--explain参数时，会对代表性语句自动执行
EXPLAIN（需确保账号有权限） 用
--filter可写 Perl 表达式过滤，比如只分析某张表或某个用户发起的慢查
注意：
pt-query-digest解析过程本身较耗 CPU，生产环境避免在高峰时段实时分析大日志文件；建议先用
head -n 100000截取样本再分析。
慢日志 + Performance Schema 联合定位真实瓶颈
仅靠慢日志会漏掉两类关键问题：一是执行快但等待长的语句（如锁等待、IO 等待），二是未达
long_query_time阈值但累积耗时高的短查询。这时要打开 Performance Schema：
确认启用：
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events%'，确保
events_statements_history_long和
events_waits_history_long为
ENABLED。
典型排查链路：
查最耗时的语句：SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5查锁等待热点：
SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE 'wait/synch/mutex%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5关联线程与慢日志：
SELECT * FROM performance_schema.threads t JOIN mysql.slow_log s ON t.PROCESSLIST_ID = s.mysql_version_id（需日志中含
mysql_version_id字段，5.7+ 支持）
Performance Schema 数据是内存中的，重启即丢失；且开启后有一定性能开销（通常
