MySQL从库慢查询日志默认不记录用户查询，仅记录SQL线程重放relay log的复制操作；需显式启用log_slow_slave_statements=ON才能记录复制语句，而用户查询是否记录取决于slow_query_log、long_query_time和log_output配置。
从库慢查询日志默认不记录用户查询，只记录复制线程行为
MySQL 从库的 slow_query_log 默认开启后，**仍不会记录你通过客户端执行的 SELECT、UPDATE 等语句**——它只记录 SQL 线程重放 relay log 的内部操作（即复制过程本身）。这是设计使然，不是配置遗漏。真正要捕获业务查询变慢，必须确认两件事：一是 slow_query_log 本身为 ON，二是 log_slow_slave_statements 这个开关是否显式启用。
log_slow_slave_statements = ON 才能记录从库上执行的用户 SQL
log_slow_slave_statements 是 MySQL 5.7.3+ 引入的独立控制项，决定是否把「从库 SQL 线程自身执行的语句」记入慢日志。但它**不影响你用 mysql 客户端连上去执行的查询**——那些属于用户连接，天然受 slow_query_log 和 long_query_time 控制。
- 设为
ON：relay log 里重放的每条语句（如INSERT INTO t1 ...）都参与慢查询判断 - 设为
OFF（推荐线上默认）：避免把system lock、Waiting for semi-sync ACK这类复制等待误判为“慢 SQL” - 注意：该参数对用户连接发起的查询完全无影响；它只过滤 SQL 线程行为
为什么开了 log_slow_slave_statements 还看不到自己的查询？
常见误解是开了这个参数就能看到自己 SELECT * FROM orders WHERE created_at > '2026-05-01' 的慢日志——但实际不会。原因很直接：
-
log_slow_slave_statements只作用于 SQL 线程，而你的查询走的是普通连接线程 - 要让自己的查询进日志，只需确保：
slow_query_log = ON、long_query_time设得合理（比如1）、且log_output包含FILE - 从库上执行
SELECT SLEEP(2)测试时，如果没进日志，优先查SHOW VARIABLES LIKE 'log_output'—— 默认是NONE，必须显式设成FILE或TABLE
从库慢日志里全是 “system lock” 怎么办
这是 log_slow_slave_statements = ON 的典型副作用。SQL 线程在重放 relay log 时，遇到锁等待、半同步 ACK 超时等场景，整个语句执行时间会拉长，触发慢日志记录。但这类“慢”不是业务问题，而是复制机制导致的假阳性。
- 解决方案：设
log_slow_slave_statements = OFF（MySQL 5.7.3+），彻底屏蔽复制线程日志 - 若需保留部分管理语句，可额外加
log_slow_admin_statements = OFF，避免ANALYZE TABLE等干扰 - 真正排查业务慢查，请专注用户连接产生的日志，别被复制线程的噪音带偏
真正容易被忽略的是：从库慢日志的时间戳是语句「执行完成」时间，不是主库提交时间。当主从延迟 30 秒时，日志里显示“14:00:00 执行了慢查询”，实际那条语句在主库可能是 13:59:30 提交的——差的这 30 秒，就是复制延迟本身。
