必须改配置文件并重启，临时set global在生产环境不可靠；需验证slow_query_log_file路径存在且mysql进程有写权限、slow_queries状态值变化、tail -f实时追加日志三要素，缺一不可。
必须改配置文件并重启，临时 SET GLOBAL 在生产环境基本不可靠。 XAMPP、云数据库、容器化部署中，连接复用、权限限制、服务管理机制会让动态设置瞬间失效，而你根本察觉不到日志其实没在记录。
确认 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 设为 1.0 是起点，不是终点
设成 0.1 秒在 OLTP 场景下极易让磁盘 IO 打满，而设成 5 秒又漏掉大量正在恶化的查询。更关键的是：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 秒，瓶颈其实在锁或连接池
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]段并重启 - 如果用了 ORM 自动生成 SQL，很多简单查询本就不走索引，此时开这个选项反而掩盖真正耗时的 JOIN 或子查询
最易被忽略的一点：慢日志只记录“执行完成”的语句。超时中断、客户端断连、事务未提交的查询，都不会进入日志——这意味着你看到的日志只是瓶颈的子集，不是全貌。先确保日志真实写入，再谈分析，否则所有优化动作都在空中楼阁。
