必须验证三件事：slow_query_log_file路径是否存在、mysql进程是否有写权限、执行select sleep(2)后slow_queries计数是否加1，并实时查看日志文件是否有新行追加，否则日志未真正落盘。
确认 slow_query_log 是否真正写入磁盘
很多人看到 SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 就以为成了，但日志可能根本没落盘。关键要验证三件事：
-
SHOW VARIABLES LIKE 'slow_query_log_file'返回的路径是否存在？MySQL 进程（不是当前登录用户）是否有写权限？XAMPP 默认以 Windows 当前用户运行，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 设置后为什么没生效？
它只对新建立的连接生效，已有连接（比如应用池里的长连接）仍按旧值判断。执行 SET GLOBAL long_query_time = 1.0 后，必须关闭当前 MySQL 客户端再重连，否则 SHOW VARIABLES 看到的仍是旧值。
- MySQL 5.7 只保留 1 位小数，
0.098会被截成0.0；8.0+ 支持微秒，但需配合log_slow_extra=ON才能显示完整精度 - 该值只统计语句执行时间，不含锁等待、网络延迟、解析开销——所以
Query_time: 0.4的语句，实际接口耗时可能是 2 秒，瓶颈其实在锁或连接池 - 设为
0会强制记录所有查询（含SELECT 1），极易撑爆磁盘，仅限临时诊断
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 才记录” - 该参数不支持动态修改（MySQL 5.7+ 部分版本支持，但云厂商常禁用），必须写进
[mysqld]段并重启 - 即使开了这个开关，也不会记录
WHERE条件恒为假却未走索引的语句——因为rows_examined是 0，不满足阈值
为什么 SET GLOBAL 在生产环境基本不可靠？
必须改配置文件并重启。临时 SET GLOBAL 在 XAMPP、云数据库、容器化部署中极易失效：连接复用会让新设置对已有连接无效；权限限制可能导致命令静默失败；服务管理机制（如 Kubernetes liveness probe 触发的自动重启）会让设置瞬间丢失，而你根本察觉不到日志其实没在记录。
- 配置项必须放在
[mysqld]段内，写在[client]或文件末尾无效 - 路径中的反斜杠要写成正斜杠或双反斜杠：
slow_query_log_file = "C:/xampp/mysql/logs/mysql-slow.log"，写成C:\xampp\...会导致 MySQL 启动失败 - 改完必须通过控制面板「重启 MySQL」，仅重启 Apache 或整个 XAMPP 不够
最容易被忽略的是：日志文件路径的权限归属和连接生命周期。哪怕配置全对，只要 MySQL 进程没权限写入目标目录，或者应用一直复用旧连接，你就永远看不到那条 Query_time: 2.345678。
