STATEMENT模式导致主从复制变慢，因从库需重放含NOW()、UUID()等非确定性函数的SQL，执行环境差异引发锁等待、全表扫描或临时表，大表UPDATE/DELETE时SQL线程易卡住，表现为Seconds_Behind_Master持续增长及Waiting for table metadata lock等状态。
为什么 binlog_format=STATEMENT 会导致主从复制变慢
当主库执行大量含非确定性函数（如 NOW()、UUID()、USER()）或依赖会话变量的语句时，STATEMENT 格式会让从库重放整个 SQL，但执行环境不同可能触发锁等待、全表扫描或临时表，尤其在大表 UPDATE 或 DELETE 场景下，从库回放线程容易卡住。
常见现象包括：Seconds_Behind_Master 持续增长、从库 SHOW PROCESSLIST 中出现 Waiting for table metadata lock 或长时间 Updating 状态。
- 确认当前格式：执行
SELECT @@binlog_format;，返回值为STATEMENT即存在风险 - 检查慢复制时段的 binlog 内容：
mysqlbinlog --base64-output=DECODE-ROWS -v /path/to/mysql-bin.000001 | grep -A5 -B5 "UPDATE.*WHERE"，观察是否含非确定性表达式 -
STATEMENT下某些语句会被自动降级为ROW记录（如含UUID()），但降级逻辑不透明，实际行为难预测
如何安全切换到 ROW 格式而不中断复制
直接改全局变量只影响新连接，已有连接仍用旧格式；且从库必须同时支持 ROW 才能解析，否则复制直接中断。关键不是“能不能切”，而是“切完会不会让从库崩溃或跳过数据”。
- 先在从库执行
STOP SLAVE;，再设SET GLOBAL binlog_format = 'ROW';—— 这步仅确保从库能解析后续日志，不改变主库行为 - 主库切换前，确认所有业务 SQL 不依赖
STATEMENT特性（如基于 SQL 的条件判断、存储过程里用@var做控制流） - 主库修改需重启或动态设置：
SET PERSIST binlog_format = 'ROW';（MySQL 8.0+）或写入配置文件my.cnf的[mysqld]段并重启 - 切换后立刻检查：
SHOW MASTER STATUS;和从库SHOW SLAVE STATUS\G中Retrieved_Gtid_Set与Executed_Gtid_Set是否持续追平
ROW 格式下复制慢的真正原因和排查路径
很多人以为切到 ROW 就万事大吉，结果发现复制延迟反而更大——这通常是因为 ROW 日志体积暴增，网络传输或磁盘 I/O 成瓶颈，或者从库缺少对应索引导致 WHERE 条件无法走索引，逐行比对主键后才更新。
- 查 binlog 事件大小：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A2 "### UPDATE" | head -20，看单条UPDATE是否携带上百列旧值/新值 - 从库执行
EXPLAIN对应的UPDATE语句（用SHOW SLAVE STATUS中的Master_Host和Master_Port连主库查原 SQL，或解析 binlog 获取完整条件） - 检查从库表是否有缺失索引：
SELECT * FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'tbl_name' AND COLUMN_NAME IN ('id', 'status'); - 若主库有大事务（如批量导入），
ROW会把所有变更打成一个 event，从库必须一次性处理完才更新Exec_Master_Log_Pos，表现为“延迟突然跳涨后归零”
哪些场景仍要谨慎用 MIXED 而非强行 ROW
MIXED 是折中方案，但 MySQL 不会告诉你它什么时候选 STATEMENT、什么时候切 ROW，日志格式不可控，排查延迟时反而更难定位源头。
- 除非明确知道某类语句（如带
LOAD DATA INFILE）在ROW下不被支持，否则不要用MIXED -
MIXED模式下，INSERT ... SELECT可能被记录为STATEMENT，如果子查询涉及非确定性函数，问题照旧 - 监控上必须额外加一条规则：定期查
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 10，看Event_type是否混杂Query和Table_map，混用即说明MIXED已生效但不可追溯
最麻烦的不是格式本身，是业务 SQL 里藏着的隐式依赖——比如用 @counter := @counter + 1 做排序编号，这种在 ROW 下根本不会记录，切完就丢逻辑。得先扫一遍所有存储过程、触发器、应用层拼接 SQL，把这类东西干掉，再谈格式切换。
