MySQL从库慢查询日志未生效是因为该配置不通过binlog同步，需手动启用；常见原因包括配置未加载、权限不足、未关闭log_slow_slave_statements导致误录复制等待。
从库开启慢查询日志为什么没生效
MySQL 从库默认关闭 slow_query_log，即使主库开了，也不会自动同步这个配置。它不走 binlog 复制，必须手动在从库上显式启用。
常见错误现象：SHOW VARIABLES LIKE 'slow_query_log' 返回 OFF；mysqld 进程启动后查不到 slow.log 文件；用 SELECT SLEEP(10) 测试也不写入日志。
- 确认从库配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf）中已添加：slow_query_log = ON<br>slow_query_log_file = /var/log/mysql/mysql-slow.log<br>long_query_time = 2
-
long_query_time在从库建议设得比主库更小（比如 1 或 0.5），因为从库通常只读、资源更紧张，轻微慢查也值得捕获 - 重启
mysqld或执行SET GLOBAL slow_query_log = ON（但后者在服务重启后失效） - 检查
slow_query_log_file路径权限：MySQL 用户（如mysql）必须有写权限，否则静默失败
从库慢日志里为什么全是“system lock”或“Waiting for semi-sync ACK”
这是典型误判：这些不是用户 SQL 慢，而是复制线程或半同步等待导致的“假慢”。MySQL 的慢日志会记录所有超过 long_query_time 的语句执行阶段，包括复制线程内部等待。
使用场景：排查真实业务查询延迟时，这类日志反而干扰判断。
- 加参数
log_slow_slave_statements = OFF（MySQL 5.7.3+）可禁止记录从库 SQL 线程执行的语句（即 relay log 重放内容） - 若用的是 MySQL 8.0+，还可配合
log_slow_admin_statements = OFF屏蔽ANALYZE TABLE等管理语句 - 注意：
log_slow_slave_statements不影响用户连接发起的查询，只过滤 SQL 线程自身行为
主从延迟大时，慢日志时间戳不准怎么办
从库慢日志里的时间戳是语句「执行完成」时间，不是「开始执行」或「主库提交」时间。当主从延迟几十秒甚至几分钟时，日志里显示“10:00:00 执行了慢查询”，实际这条语句在主库可能是 09:59:20 提交的 —— 时间差就是复制延迟。
这会导致按时间排查问题时错位，尤其和应用日志对不上。
- 务必同时采集
Seconds_Behind_Master（用SHOW SLAVE STATUS查），在分析慢日志时间段时反向推算主库大致时间点 - 避免单独依赖慢日志时间戳做根因定位；优先结合
pt-query-digest分析日志，并用--since和--until配合延迟值做时间窗口修正 - 如果启用了 GTID，可用
SELECT MASTER_POS_WAIT('xxx', xxx)辅助验证某条事务是否已在从库落地
慢日志文件轮转后，从库会不会丢日志
不会自动丢，但容易因配置疏漏导致新日志写不进磁盘，表现为日志停止增长且无报错。
关键点在于：MySQL 自身不管理慢日志轮转，全靠外部工具（如 logrotate）或人工 FLUSH LOGS，而从库常被忽略轮转逻辑。
- 若用
logrotate，确保配置中包含create 644 mysql mysql和postrotate ... mysql -e "FLUSH LOGS" ... endscript - 不要只在主库配轮转，从库必须独立配置 —— 因为
slow_query_log_file是本地路径，且主从可能部署在不同机器 - 检查
max_slow_log_file_size（MySQL 8.0.25+）是否设限，过小可能导致日志被截断而不报错
log_slow_slave_statements 这个开关，一漏就白开。 
