MySQL慢查询日志默认关闭，必须显式设置slow_query_log=ON才生效；可通过SET GLOBAL动态开启（重启失效）或修改my.cnf永久配置，并需确保slow_query_log_file路径可写、long_query_time阈值合理。
慢查询日志默认是关闭的，必须手动启用
MySQL 的 slow_query_log 默认值为 OFF，哪怕你配置了 slow_query_log_file 或 long_query_time，日志也不会写入。必须显式设为 ON 才生效。
有两种启用方式：
- 运行时动态开启（重启后失效）：
SET GLOBAL slow_query_log = ON; - 永久生效需修改配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]段落添加：slow_query_log = ON<br>slow_query_log_file = /var/log/mysql/mysql-slow.log<br>long_query_time = 1.0
- 注意：
long_query_time单位是秒，支持小数（如0.5），但 MySQL 5.7+ 默认精度为微秒级，实际判断仍以整秒为单位截断——比如设为0.1，真正记录的是 ≥100ms 的查询；而0.0表示记录所有查询（含未使用索引的）
log_queries_not_using_indexes 是个“陷阱开关”
这个配置项容易被误用。它不是“记录没走索引的慢查询”，而是“只要没走索引，不管执行多快都记”。开启后日志量可能爆炸，尤其在有大量 SELECT * 或低效 WHERE 条件的系统中。
建议只在排查索引缺失问题时临时开启，生产环境慎用：
- 确认是否真需要：
SELECT @@log_queries_not_using_indexes; - 临时启用：
SET GLOBAL log_queries_not_using_indexes = ON; - 搭配
long_query_time = 0使用才有意义，否则两者逻辑不叠加 - 记得关掉：
SET GLOBAL log_queries_not_using_indexes = OFF;
用 mysqldumpslow 分析日志前先检查权限和路径
mysqldumpslow 是 MySQL 自带的分析工具，但它不读取远程或任意路径的日志——必须确保：
- MySQL 进程用户（如
mysql）对日志文件有读权限，否则mysqldumpslow会报Can't read from file - 路径必须绝对且正确，比如：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log -
-s t表示按总执行时间排序，-t 10取前 10 条；常用组合还有-s c（按出现次数）、-a（不抽象化 SQL 中的数字和字符串） - 如果日志过大（>1GB），
mysqldumpslow会卡住甚至 OOM，此时应先用grep或awk初筛，例如：awk '/Query_time/{print $2,$3,$4,$5,$6,$7}' /var/log/mysql/mysql-slow.log | sort -nr | head -20
Percona Toolkit 的 pt-query-digest 更适合真实运维场景
mysqldumpslow 功能简陋，无法聚合参数化 SQL、缺少执行计划关联、不支持输出 HTML 或 JSON。线上问题定位强烈推荐 pt-query-digest：
- 安装：
apt install percona-toolkit（Debian/Ubuntu）或yum install percona-toolkit（RHEL/CentOS） - 基础用法：
pt-query-digest /var/log/mysql/mysql-slow.log - 关键能力：
– 自动归一化 SQL（把WHERE id=123和WHERE id=456合并统计）
– 输出EXPLAIN建议（加--explain参数，需连接目标库）
– 支持从 TCP 流实时解析（--processlist）或从 Performance Schema 抽取（--plugin） - 注意：
pt-query-digest默认只分析最近 1 小时日志，加--since "2024-06-01 00:00:00"可指定时间范围
慢查询日志本身不记录锁等待、网络延迟或客户端超时，它只反映服务器端执行耗时。真正卡顿的请求，可能根本没进慢日志——比如卡在连接池排队、DNS 解析失败、或事务被长事务阻塞。别只盯着 Query_time。
