慢查询日志（slow_query_log）仅记录主库本地执行超时的SQL，不写入binlog，也不同步至从库；真正同步的是binlog中的数据变更事件，从库执行快慢取决于自身环境。
慢查询本身不会被同步，因为“慢”是执行时长的判断结果，不是 binlog 里的内容；真正被同步的是 SQL 语句（或行变更事件），从库执行它时快慢取决于自身环境。
主库的 slow_log 和 binlog 是两套独立机制
MySQL 的 slow_query_log 是诊断日志，只记录主库本地执行超过 long_query_time 的语句，不写入 binlog，也不传输给从库。binlog 只记录实际变更数据的逻辑（STATEMENT）或物理行（ROW）事件——和“执行耗时”无关。
也就是说：
- 主库一条 UPDATE 耗时 8 秒，只要成功提交，就会写 binlog；
- 从库收到后重放这条语句，可能 0.2 秒就完成（硬件强、无锁争用），也可能卡住 15 秒（磁盘慢、有大锁、没索引）。
为什么从库执行同一语句可能更慢？
- 从库默认单线程回放（
slave_parallel_type = DATABASE或未启用 MTS），而主库可并发执行 - 从库正在跑备份（
mysqldump或xtrabackup）触发FLUSH TABLES WITH READ LOCK，阻塞 SQL 线程 - 从库
innodb_buffer_pool_size过小，大量磁盘随机读；主库 buffer pool 已热，执行快 - 从库表上缺失主库已有的索引，导致
UPDATE/DELETE全表扫描 - 从库开启了
read_only = ON，但某些操作（如 GTID 补位、心跳表写入）仍需临时关闭，引发短暂锁等待
如何判断是不是“同一条语句在从库变慢”？
别只看 Seconds_Behind_Master，它只是估算值，且在 SQL 线程卡死时会失真。更可靠的方式：
在从库执行：SHOW PROCESSLIST; —— 找到 State 为 Updating / Copying to tmp table / Locked 的 system user 线程SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND USER = 'system user';
再结合 SHOW ENGINE INNODB STATUS\G 查当前锁和事务等待链。
如果发现某条语句长期卡在从库，而主库早已完成，说明问题出在从库执行环境，不是“慢查询被跳过”——它根本没被跳过，而是卡住了。
容易被忽略的关键点：binlog_format 决定“同步什么”，而不是“同步多快”
binlog_format = STATEMENT 时，从库要重新解析并执行原始 SQL，性能高度依赖从库执行计划是否和主库一致（比如函数、临时表、用户变量）；binlog_format = ROW 时，从库只按行变更 apply，不走 SQL 解析，但遇到大 BLOB 或大批量 UPDATE，relay log 写入和解析开销反而上升。
所以不是“慢查询不同步”，而是：
- 主库慢，是因为它执行时资源争抢或计划差；
- 从库慢，是因为它回放时面临不同的资源瓶颈或配置偏差。
两者独立，但共享同一份 binlog 输入。
