必须新建连接验证，因slow_query_log动态开启后仅对新连接生效；需同时确认select @@global.slow_query_log和@@session.slow_query_log均为on，并用mysql -u root -p新连执行sleep(2)测试日志是否落盘。
确认 slow_query_log 是否真正生效
动态执行 SET GLOBAL slow_query_log = 'ON' 后，日志并不会立刻在当前连接中记录——slow_query_log 是只读全局变量，仅对新建立的连接生效。常见误判是看到 SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 就以为万事大吉，其实当前会话仍用的是旧配置。
必须验证两件事：
- 执行 SELECT @@global.slow_query_log 和 SELECT @@session.slow_query_log，两者都得是 1 或 ON
- 用全新命令行连接测试：如 mysql -u root -p，再跑一条明确超时的 SQL（例如 SLEEP(2)），然后检查日志文件是否有新增条目
- 某些 GUI 工具或连接池（如 Druid、HikariCP）会复用连接，不继承新全局设置，这类场景下必须重启应用或刷新连接池
long_query_time 设为 0.5 为什么没捕获到 600ms 的查询？
因为 long_query_time 的精度受 MySQL 版本限制：5.7 及以前只保留一位小数，0.5 实际可能被截断为 0.49；8.0+ 虽支持微秒级，但需配合 log_slow_extra = ON 才能体现真实精度。更重要的是，它只统计语句在存储引擎层的实际执行时间，不含网络延迟、解析开销、锁等待等。
建议做法：
- 初期设为 1，用 mysqldumpslow 观察日志中典型查询的耗时分布
- 若发现大量查询集中在 0.7–0.9 秒，再尝试下调至 0.5，并用 SLEEP(0.8) 验证是否落日志
- 绝对避免设为 0：这会让所有查询（包括 SELECT 1）写入日志，高并发下极易撑爆磁盘 I/O 和空间
开启 log_queries_not_using_indexes 后日志爆炸怎么办？
这个开关一开，MySQL 会对每个未走索引的查询打日志，哪怕 WHERE id = -1 这种恒假条件、只扫描 1 行的语句也会记——结果就是日志里全是噪音，真正需要关注的低效全表扫描反而被淹没。
必须同步配置：
- min_examined_row_limit = 100（或根据业务调为 500/1000）：表示“未走索引且扫描行数 ≥ 该值才记录”
- 注意：该参数在 MySQL 5.7+ 支持动态设置，但很多云厂商（如阿里云 RDS、腾讯云 CVM）定制版禁用，只能写进 my.cnf 并重启
- 不要依赖 log_queries_not_using_indexes 来替代 EXPLAIN 分析，它只是辅助线索，不是根因诊断工具
日志路径权限不足导致 silent fail
MySQL 写慢日志失败时通常不报错，只会静默跳过——你看到 slow_query_log 是 ON，但日志文件始终为空，大概率是路径权限问题。
检查要点：
- 确认 slow_query_log_file 所在目录由 mysql 用户可写（ls -ld /var/log/mysql）
- 若路径含多级目录（如 /data/mysql/log/slow.log），每一级都要有 mysql 用户的 x（执行）权限才能进入
- 使用 touch /path/to/slow.log && chown mysql:mysql /path/to/slow.log 测试写入能力
- 日志目录所在磁盘剩余空间建议 ≥ 2GB，否则日志轮转失败后可能直接中断写入
实际配置中最容易被忽略的，是“新连接才生效”这个行为边界，以及 min_examined_row_limit 对 log_queries_not_using_indexes 的必要约束——这两点不处理，日志要么根本不出，要么满屏无用信息。
