大事务会直接拉高seconds_behind_master，因为从库sql线程串行回放binlog事件，一个耗时10秒的大事务会阻塞后续所有事务执行，导致延迟线性上涨；拆分需按主键id范围分批（如between）、limit+order by滚动推进、显式commit，禁用offset。
为什么大事务会直接拉高Seconds_Behind_Master
MySQL从库的SQL线程是串行回放binlog事件的（即使开了并行复制，事务边界仍受组提交约束）。一个耗时10秒的UPDATE语句，无论它改1行还是100万行，都会阻塞后续所有事务的执行。此时Seconds_Behind_Master会线性上涨，而不是“等这个事务做完再开始算”。你看到的延迟值，本质是从库当前执行位置与主库最新binlog位置之间的时间差。
拆分大事务的具体操作方式
不能只靠“尽量小”，得有可落地的切分逻辑：
- 按主键/自增ID范围分批，例如
WHERE id BETWEEN 100001 AND 200000，每次处理10万行，配合COMMIT - 用
LIMIT+ORDER BY id滚动推进，避免OFFSET深分页性能坍塌 - 对
DELETE或UPDATE加AND updated_at 等时间条件，天然限流 - 业务层控制：批量导入时，每500–1000条INSERT封装为一个事务，而非全量包在一个事务里
哪些“看起来小”的事务其实很危险
事务大小不等于SQL语句长度，而取决于它实际修改的数据页数量和锁持有时间：
UPDATE t SET status=1 WHERE create_time —— 即使没加索引，也可能扫全表并锁住数万行-
ALTER TABLE t ADD COLUMN x INT DEFAULT 0—— DDL在MySQL 5.7+虽支持online，但仍是长事务，会阻塞复制线程 - 带子查询的UPDATE，如
UPDATE t1 SET a=(SELECT b FROM t2 WHERE t2.id=t1.id)，若t2无索引，每个t1行都触发一次全表扫描 - 未显式
START TRANSACTION的单条语句，在autocommit=1下仍是独立事务，但高频小事务会抬高IO压力，间接拖慢relay log应用
验证事务拆分是否生效的关键指标
别只盯Seconds_Behind_Master，它滞后且易受网络抖动干扰。更直接的证据是：
- 从库
SHOW PROCESSLIST中SQL线程状态是否长期停留在executing（说明还在跑单个大事务） - 对比
Relay_Master_Log_File和Exec_Master_Log_Pos的差值是否稳定收敛（说明relay log在被持续消费） - 用
pt-heartbeat查mysql.heartbeat表，看写入时间戳与从库当前时间差是否从分钟级降到秒级内 - 开启
slow_query_log并设long_query_time=1，确认从库慢日志里不再出现执行超5秒的DML
