STATEMENT格式易致主从数据不一致，因仅记录SQL语句而忽略执行上下文；推荐统一使用ROW格式，并通过三步安全切换；sync_binlog=1与innodb_flush_log_at_trx_commit=1或2组合兼顾安全与性能；从库需开启read_only防止误写。
为什么 STATEMENT 格式在主从复制中容易出错
因为 STATEMENT 只记录 SQL 语句本身，不记录执行时的实际数据上下文。一旦语句里有函数（比如 NOW()、UUID()、USER()）或依赖会话变量（如 @var），从库重放时结果很可能和主库不一致，导致数据漂移。
常见错误现象：Slave_SQL_Running: No，查 SHOW SLAVE STATUS\G 发现 Last_SQL_Error 提示“Column count doesn’t match”或函数不可重现；更隐蔽的是数据对不上但复制没报错。
- 除非你 100% 确保所有写操作都是确定性 SQL（无函数、无变量、无临时表），否则别用
STATEMENT -
MIXED是自动降级策略，看似省心，但判断逻辑黑盒化，反而让问题更难复现和定位 - 生产环境统一用
ROW—— 它记录的是行变更前后的镜像，主从一致性有保障
怎么安全地把 binlog_format 从 STATEMENT 切到 ROW
不能直接改全局变量，因为已有连接仍沿用旧格式，可能造成混合日志，引发从库解析失败。必须让新连接和后续所有写入都走新格式。
实操分三步：
- 先在主库执行
SET GLOBAL binlog_format = 'ROW'，再确认生效：SELECT @@binlog_format - 重启所有应用连接池（或等旧连接自然断开），确保新连接使用新格式；重点检查 ORM 是否缓存了连接并复用旧会话
- 从库无需改
binlog_format（它只读不写），但要确认relay_log_format是默认值（通常不用动）
注意：ROW 日志体积更大，尤其批量更新大字段时。如果磁盘 IO 或网络带宽吃紧，得配合 binlog_row_image = MINIMAL（MySQL 5.6+）减少冗余字段记录。
sync_binlog 和 innodb_flush_log_at_trx_commit 怎么配才不丢数据又不太慢
这两个参数共同决定主库崩溃后最多丢失多少事务。设太高（比如都为 1）最安全但性能差；设太低（比如都为 0）快是快了，但主库宕机可能丢一整秒的提交。
- 推荐组合：
sync_binlog = 1+innodb_flush_log_at_trx_commit = 1：强一致性，适合金融类场景 - 折中方案：
sync_binlog = 1+innodb_flush_log_at_trx_commit = 2：InnoDB 日志刷到 OS 缓存而非磁盘，崩溃可能丢最近 1 秒事务，但性能提升明显 - 绝对不要设
sync_binlog = 0：binlog 不刷盘，主库崩溃后从库无法追平，复制链直接断裂
验证是否生效：在主库执行 SHOW VARIABLES LIKE 'sync_binlog' 和 SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'，两个值必须是你设的数字，不是只读变量。
从库延迟高，光调 slave_parallel_workers 不够
单纯增加并行线程数（比如设成 8）在多数场景下效果有限，甚至可能因锁竞争更慢。真正瓶颈常在单个 Relay Log 文件解析或 SQL 线程争抢同一个表。
- 先看
SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Slave_SQL_Running_State：如果是 “Reading event from the relay log”，说明 Relay Log 解析慢，优先优化磁盘 IO 或换 SSD - 如果是 “System lock” 或 “Updating”，大概率是热点表冲突，考虑开启
slave_parallel_type = LOGICAL_CLOCK（MySQL 5.7+），它按事务组并行，比按库并行更细粒度 - 避免大事务：单个事务更新 10 万行，哪怕开了 8 个 worker，也得等它全部跑完才能调度下一个，延迟照样飙高
最容易被忽略的一点：从库的 read_only = ON 必须开启。否则应用误连从库写入，不仅破坏主从一致性，还会让 GTID 混乱，后续修复成本极高。
