MariaDB 慢查询日志配置 long_query_time 不生效，最常见原因是慢查询日志总开关 slow_query_log 处于关闭状态，或者变量作用域 SESSION 与 GLOBAL 设置不一致。检查日志文件写入权限和 min_examined_row_limit 限制也能解决大部分问题。
先说结论：确认 slow_query_log 已开启，区分 SESSION 与 GLOBAL 作用域，并验证日志文件权限。
- 先确认：检查 slow_query_log 变量值是否为 ON 或 1。
- 先处理：根据需求设置 GLOBAL 或 SESSION 级别的 long_query_time。
- 再验证：执行超时查询语句并查看日志文件是否有新记录。
命令速用版
以下命令用于快速检查状态和临时开启日志，重启后失效：
SHOW VARIABLES LIKE 'slow_query_log';
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SHOW VARIABLES LIKE 'slow_query_log_file';
为什么会这样
long_query_time 不生效的核心原因是慢查询日志总开关未打开，或变量作用域设置未匹配当前会话。
MariaDB 中 long_query_time 仅当 slow_query_log 启用时才参与判断。若总开关关闭，即使查询时间超过阈值也不会记录。此外，SESSION 级别的设置仅影响当前连接，GLOBAL 级别的设置影响新连接，混淆两者会导致配置看似未生效。
分步处理
按顺序检查开关、时间阈值、文件路径和权限，确保配置链路完整。
1. 确认日志开关状态：执行 SHOW VARIABLES LIKE 'slow_query_log';，确保 Value 为 ON 或 1。
2. 确认时间阈值：执行 SHOW VARIABLES LIKE 'long_query_time';，确认数值符合预期（单位秒）。
3. 确认日志文件路径：执行 SHOW VARIABLES LIKE 'slow_query_log_file';，记录文件绝对路径。
4. 检查文件权限：在操作系统层面确认 mysql 用户对该路径有写入权限，避免 Permission denied。
怎么验证是否生效
通过执行故意超时的查询语句，检查日志文件是否新增记录。
1. 设置 long_query_time 为 1 秒。
2. 执行 SELECT SLEEP(2); 语句。
3. 查看慢查询日志文件末尾，确认是否出现该语句的执行记录。
4. 若日志无变化，检查错误日志 error log 是否有写入报错。
常见坑
注意 MariaDB 特有的过滤变量和管理员语句排除规则，避免误判配置失效。
1. min_examined_row_limit：若设置该值，扫描行数低于限制的查询即使超时也可能不记录。
2. log_slow_filter：该变量可过滤特定类型的查询，配置不当会拦截日志。
3. 管理员语句：部分管理命令默认不记录到慢查询日志，需检查 log_slow_admin_statements 设置。
4. 动态生效范围：SET GLOBAL 不影响已建立的连接，需重新登录会话验证。
常见问题
修改 long_query_time 后为什么当前会话没变化？
因为变量作用域是 GLOBAL，当前会话仍沿用旧值。
需要断开重连或针对当前会话执行 SET SESSION long_query_time = 值。
日志文件为空但错误日志有报错怎么办？
通常是 mysql 用户对日志文件路径没有写入权限。
使用 chown 或 chmod 修正文件所属用户和权限。
微秒级查询能否被记录？
默认 long_query_time 精度为秒，微秒级需配合 use_microseconds 配置。
MariaDB 10.5+ 支持更细粒度，但需确认版本特性。