mysql默认不开启慢查询日志且long_query_time默认10秒，需set global动态启用并设为浮点数（如1.0），生产环境必须写入my.cnf的[mysqld]段并重启生效，配合mysqldumpslow分析日志。
如何设置 slow_query_log 和 long_query_time
MySQL 安装完默认不开启慢查询日志，long_query_time 通常默认是 10 秒，对线上服务来说完全没用。必须手动启用并调低阈值才能捕获真实慢 SQL。
- 先确认当前状态：
SHOW VARIABLES LIKE 'slow_query_log';和SHOW VARIABLES LIKE 'long_query_time'; - 动态开启（重启不丢失需写入配置文件）：
SET GLOBAL slow_query_log = 'ON'; - 设阈值为 1 秒：
SET GLOBAL long_query_time = 1.0;（注意：必须是浮点数，1会被当整型忽略） - 日志路径默认由
slow_query_log_file决定，建议显式指定，比如：SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';
⚠️ 重点：long_query_time 是针对单条语句执行时间，不包含锁等待、网络传输等；且在事务中，只有 COMMIT 或语句真正执行完成才判定，BEGIN 后的语句不单独计时。
my.cnf 中必须配置的几项
仅靠 SET GLOBAL 是临时的，MySQL 重启就失效。生产环境必须写进配置文件，否则监控会断档。
- 在
[mysqld]段落添加：slow_query_log = ON -
slow_query_log_file = /var/log/mysql/mysql-slow.log（确保 MySQL 进程有写权限） -
long_query_time = 1.0（再次强调小数点） - 可选但推荐：
log_queries_not_using_indexes = ON，方便发现缺失索引的查询（但会显著增加日志量）
改完配置后必须重启 MySQL：systemctl restart mysqld（或 mysqld_safe 方式），仅 reload 不生效。
用 mysqldumpslow 快速分析慢日志
原始慢日志是纯文本，直接 tail -f 看效率低。MySQL 自带的 mysqldumpslow 能聚合统计，是日常巡检首选工具。
- 看最慢的 10 条：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log - 看访问次数最多的：
mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log - 过滤某个库的慢查：
mysqldumpslow -d mydb /var/log/mysql/mysql-slow.log
⚠️ 注意：mysqldumpslow 会读取整个日志文件，大日志（>1GB）会卡住；建议配合 logrotate 每天切分，并只分析最近一份。
常见监控盲区和误判点
很多团队配了慢日志却漏掉关键问题，往往不是不会配，而是忽略了这些细节：
-
long_query_time在 5.7+ 支持微秒级（如0.1），但 5.6 及更早版本最小只能设到1.0，升级前别盲目调低 - 如果用了代理（如 ProxySQL、MaxScale），慢日志只记录到达 MySQL 的语句，不包含代理层耗时；真实端到端延迟可能远超
long_query_time -
SET SESSION long_query_time = 0.5对当前连接有效，但无法让已有慢查询“回溯”记录——它只影响后续执行 - 慢日志不记录
SELECT SLEEP(2)这类显式休眠，但会记录因锁等待导致的执行延迟
真正难的不是打开开关，而是把 long_query_time 设得既够敏感又不刷屏，还得确保日志能被持续采集、解析、告警——这中间缺一环，慢查就等于没监控。
