慢查询日志本身不直接揭示瓶颈，需结合rows_examined、lock_time、query_time组合解读；必须验证slow_query_log_file路径权限、slow_queries状态值变化及实时日志追加，且long_query_time对新连接生效，log_queries_not_using_indexes须配合min_examined_row_limit防日志爆炸。
慢查询日志本身不直接告诉你瓶颈在哪，它只记录“谁跑得慢”；真正定位瓶颈，得靠日志里 Rows_examined、Lock_time、Query_time 这几个字段的组合解读，而不是只盯着耗时排序。
确认 slow_query_log 真正在写入磁盘，不是“开着但没记”
很多人执行 SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 就以为万事大吉，结果查了一周日志全是空的。关键要验证三件事是否同时成立：
-
SHOW VARIABLES LIKE 'slow_query_log_file'返回的路径必须存在，且 MySQL 进程用户（比如mysql或root）对该目录有写权限——Windows 下 XAMPP 默认路径C:\xampp\mysql\data\常因 UAC 拦截失败，建议改到C:/xampp/mysql/logs/并手动创建目录 -
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 设对了，但旧连接仍按老值判断
long_query_time 是浮点数，且只对新建立的连接生效。应用池里的长连接、ORM 的连接复用、甚至你当前 MySQL 客户端会话，都沿用启动时的旧值。
- 执行
SET GLOBAL long_query_time = 1.0后，必须退出当前客户端再重连，否则SHOW VARIABLES LIKE 'long_query_time'显示的仍是旧值 - MySQL 5.7 最多保留 1 位小数，
0.098会被截成0.0；8.0+ 支持微秒，但需配合log_slow_extra = ON才能显示完整精度 - 设为
0能抓全量 SQL，但极易打满磁盘 IO，生产环境务必搭配定时恢复脚本，或改用0.01（10ms）替代
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 才记录” - 该参数不支持动态修改（云厂商常禁用），必须写进
[mysqld]段并重启 MySQL - 开启后注意观察日志体积增长速度，尤其在批量导入或历史数据清理期间，可能触发磁盘告警
看日志别只盯 Query_time，Rows_examined 和 Lock_time 才是真瓶颈信号
Query_time 只统计语句执行时间，不含锁等待、网络延迟、解析开销。一条 Query_time: 0.4 的语句，接口耗时可能是 2 秒，瓶颈其实在锁或连接池。
-
Rows_examined远大于Rows_sent→ 很可能没走对索引，或存在隐式类型转换导致索引失效 -
Lock_time高（比如 > 0.3s）→ 不是 SQL 本身慢，而是被其他事务长时间持有锁阻塞，要查information_schema.INNODB_TRX和锁等待链 -
Rows_examined小但Query_time高 → 可能涉及大排序（Using filesort）、临时表（Using temporary）或函数计算（如DATE_FORMAT(NOW(), '%Y-%m')）
真正容易被忽略的是：日志中每条记录的时间戳（# Time:）默认用系统时区，若业务日志用 UTC 而 MySQL 用 CST，排查时会错位整整 8 小时——务必统一时区配置再开始分析。
