结论：long_query_time必须设为浮点数（如1.0）且slow_query_log=ON才生效；仅调阈值不开启日志无效，SET GLOBAL long_query_time=1不起作用主因是slow_query_log仍为OFF、旧连接未刷新会话值或赋值未用小数形式。
直接说结论：long_query_time 必须设为浮点数（如 1.0），且必须配合 slow_query_log = ON 才生效；仅改阈值不开启日志，等于没配。
SET GLOBAL long_query_time = 1 为什么不起作用？
常见现象是执行了 SET GLOBAL long_query_time = 1，但后续查询没进慢日志。原因通常有三个：
-
slow_query_log还是OFF—— 必须显式执行SET GLOBAL slow_query_log = 'ON'，否则阈值再低也无输出 - 当前连接仍沿用旧会话值 ——
SET GLOBAL只影响新连接，老连接需额外执行SET SESSION long_query_time = 1.0 - 写了整数
1而不是浮点数1.0—— MySQL 会忽略整数赋值，尤其在 5.7+ 版本中，long_query_time动态设置强制要求小数形式
my.cnf 里配置了 long_query_time = 0.5，重启后还是 10？
这不是配置没读取，而是配置段落写错了或被覆盖了。关键检查点：
- 必须写在
[mysqld]段下，写在[client]或[mysql]下完全无效 - 确认没有多个配置文件冲突（如
/etc/my.cnf、/etc/mysql/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf），MySQL 按顺序加载，后加载的会覆盖前一个 - 重启后验证：执行
SELECT @@global.long_query_time，返回值必须是0.500000，而不是10.000000
为什么开了 log_queries_not_using_indexes，日志暴增却抓不到真瓶颈？
这个参数和 long_query_time 是“或”关系，不是“且”——只要没走索引就记，不管执行多快。结果就是大量 SELECT * FROM tiny_table WHERE id = ? 这类毫秒级查询全进日志。
真正有用的组合是：
log_queries_not_using_indexes = ON-
min_examined_row_limit = 1000（必须写进my.cnf并重启，不能SET GLOBAL）
这样只记录“未走索引 + 扫描行数 ≥ 1000”的查询，过滤掉噪音，聚焦真实风险点。
验证配置是否真落地，别信 SHOW VARIABLES
SHOW VARIABLES LIKE 'long_query_time' 显示的是当前会话值，可能和全局不一致。最可靠验证方式是：
- 新开一个终端，用
mysql -u root -p连接（确保是全新连接） - 执行
SELECT SLEEP(2)（假设你设了long_query_time = 1.0） - 立刻
tail -f /var/log/mysql/mysql-slow.log看是否出现该语句 - 再执行一条明确不走索引的查询（如
SELECT * FROM users WHERE name LIKE '%x%'，且name无索引），确认是否也进日志
路径权限、SELinux 限制、磁盘空间不足这些底层问题，都会导致日志静默失败 —— 表面看着 slow_query_log = ON，实际一条都不写。
