MySQL慢查询日志有效性的核心在于日志是否真实落盘、配置是否对新连接生效、过滤条件是否合理，以及需结合pt-query-digest分析和锁监控补全日志盲区。
生产环境 MySQL 卡顿，90% 的根因藏在慢查询日志里——但直接开日志、设 long_query_time=1、查 slow.log，大概率白忙活。关键不是“有没有日志”，而是“日志有没有真写进去、有没有覆盖真实瓶颈、有没有被误判噪音淹没”。
确认 slow_query_log 是否真正落盘，而不是只返回 ON
很多人执行 SET GLOBAL slow_query_log = ON 后看到 SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 就以为成了，结果一查日志文件空空如也。这是因为：
- MySQL 进程（比如
mysqld）对slow_query_log_file指定路径没有写权限——XAMPP 默认用 Windows 当前用户启动，C:\xampp\mysql\data\下常被 UAC 拦截；云数据库（如阿里云 RDS、腾讯云 CDB）根本不允许你指定任意路径 -
SHOW GLOBAL STATUS LIKE 'Slow_queries'初始值不是 0，或执行SELECT SLEEP(2)后没变 1，说明日志链路断在配置/权限/服务管理某一层 - 没用
tail -f /var/log/mysql/mysql-slow.log（Linux）或Get-Content -Tail 5 "C:/xampp/mysql/logs/mysql-slow.log"（Windows）亲眼看到新行追加——“文件存在”不等于“日志在写”
long_query_time 设为 1.0 是起点，但必须重连客户端才生效
long_query_time 是浮点数，且只对新建立的连接生效。已有连接（比如应用连接池里的长连接）仍按旧值判断，你改了全局变量却看不到效果，就是这个原因。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 执行
SET GLOBAL long_query_time = 1.0后，必须退出当前 MySQL 客户端，重新登录，再运行SHOW VARIABLES LIKE 'long_query_time'才能看到更新后的值 - MySQL 5.7 最多保留 1 位小数，
0.098会被截成0.0；8.0+ 支持微秒级精度，但需配合log_slow_extra=ON才能在日志里显示完整时间戳 - 该参数只统计语句执行时间（Query_time），不含锁等待、网络延迟、解析开销——所以日志里
Query_time: 0.4的语句，接口实际耗时可能是 2 秒，瓶颈其实在行锁或连接池打满
log_queries_not_using_indexes 必须配 min_examined_row_limit
单独开启 log_queries_not_using_indexes = ON 是高危操作：它会把所有未走索引的查询都记下来，包括 SELECT * FROM users WHERE id = -1 这种扫描 0 行的无效语句，日志量爆炸且无分析价值。
- 必须同步设置
min_examined_row_limit = 100（或业务可接受的阈值），表示“未走索引 + 扫描行数 ≥ 100 才记录” -
min_examined_row_limit不支持动态修改（MySQL 5.7+ 部分版本支持，但主流云厂商默认禁用），必须写进[mysqld]段并重启 MySQL 服务 - 如果用的是 TABLE 输出（
log_output = 'TABLE'），记得检查mysql.slow_log表是否启用了general_log级别权限，否则写入失败静默丢弃
用 pt-query-digest 分析，别手动 grep
原始慢日志是纯文本，每条记录含 Query_time、Lock_time、Rows_examined 等字段，但人工翻找效率极低。真正能定位卡顿语句的是聚合分析能力：
-
pt-query-digest /var/log/mysql/mysql-slow.log --since '2026-11-04 18:00:00'可按时间窗口过滤，避免历史噪音干扰 - 报告中优先看
Count高 +Query_time平均值大的 SQL——高频慢查比偶发巨慢更危险，容易拖垮连接池 - 注意
Rows_examined和Rows_sent的比值：若前者是后者的几百倍，大概率存在全表扫描或索引失效；若两者接近但Query_time高，可能是大字段SELECT *或磁盘 IO 瓶颈
最容易被忽略的一点：慢查询日志只捕获“已执行完”的语句。如果一条 SQL 卡在锁等待上没执行完、或者被连接池超时中断，它根本不会出现在日志里——这时候得结合 SHOW ENGINE INNODB STATUS 查事务锁，或用 APM 工具看调用链中的 SQL 阶段耗时。
