大事务导致Binlog延迟是因为MySQL仅在COMMIT时批量写入binlog，期间从库无法接收任何事件；同时长事务持有行锁或MDL锁，阻塞其他操作。安全拆分需基于主键或时间戳分段、确保范围不重叠不遗漏，并具备幂等性。
大事务为什么会导致 Binlog 延迟
Binlog 写入不是独立于事务的：MySQL 只在事务 COMMIT 时才将整个事务的 binlog event 一次性写入文件（或 relay log）。一个运行 30 秒、修改 50 万行的事务，binlog 日志要等到最后 commit 才落盘——主库上看似“执行完了”，但从库根本收不到任何 binlog event，复制自然卡住。更糟的是，这个事务还长期持有 row-level 锁或 MDL 锁，阻塞其他 DDL/DML，进一步拖慢整体节奏。
如何安全拆分大事务（避免丢失/重复）
不能简单用 LIMIT 分页更新就完事。必须保证每次子事务处理的数据范围不重叠、不遗漏，且具备幂等性（重试不翻车）：
- 用自增主键或时间戳字段做切分依据，例如
WHERE id BETWEEN ? AND ?或WHERE create_time >= ? AND create_time - 每次执行前先查出当前批次最大
id（或create_time），作为下一批起点，避免因并发插入导致漏数据 - 禁用
AUTO_INCREMENT+REPLACE INTO类操作，它们可能隐式改变主键值，破坏分片连续性 - 示例安全拆分逻辑：
BEGIN;<br>UPDATE t SET status = 1 WHERE id >= 100000 AND id SELECT MAX(id) FROM t WHERE id >= 100000 AND id COMMIT;
锁粒度优化：哪些操作真能降锁，哪些只是幻觉
很多人以为加索引就能“自动变行锁”，其实不然。是否走索引、是否命中唯一索引、是否用到覆盖索引，都直接影响锁类型和范围：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 全表扫描更新（
UPDATE t SET x=1 WHERE y=999，y 无索引）→ 升级为表锁，Binlog 复制完全停滞 - 非唯一索引条件（
WHERE idx_col = 'abc'）→ MySQL 会加 gap lock，锁住可能插入的位置，范围远超实际匹配行 - 唯一索引 + 等值查询（
WHERE pk = 123）→ 只锁该行，最安全；配合SELECT ... FOR UPDATE显式加锁可避免幻读，但别滥用 - 批量更新尽量避开
OR、函数包裹字段（如WHERE DATE(create_time) = '2024-01-01'），这些都会让索引失效，触发全表扫描
Binlog 格式与 sync_binlog 配合调优
即使事务拆小了，如果 binlog 刷盘策略太保守，仍可能堆积在内存里不出去：
- 确认使用
binlog_format = ROW（语句模式下大事务日志更难解析，且容易主从不一致） -
sync_binlog = 1是最安全选择，但写入压力大时可权衡设为10或100（表示每 N 个事务刷一次磁盘） - 注意：
sync_binlog = 0表示依赖 OS 缓存，主机 crash 会导致 binlog 丢失，主从数据直接断裂，生产环境禁用 - 检查
innodb_flush_log_at_trx_commit = 1是否开启——它和sync_binlog共同决定崩溃恢复能力，两者不同步会导致主从 GTID 不一致
真正卡住复制的，往往不是单条慢 SQL，而是那个你以为“只是改得多”的事务。拆分时少依赖 LIMIT，多校验边界；加锁时别只看有没有索引，要看它是不是被真正用上。锁没缩下去，拆成一百个小事务也照样堵。
