DELETE本身不慢，慢在从库SQL线程串行回放时引发锁争用、日志堆积和事务阻塞；单条大事务导致Exec_Master_Log_Pos延迟更新、Seconds_Behind_Master失真，须分批（BETWEEN+索引）、启用LOGICAL_CLOCK并行复制并验证执行计划。
DELETE 操作本身不慢，慢的是它在从库上串行回放时引发的锁争用、日志堆积和事务阻塞。直接执行 DELETE FROM t WHERE ... 千万级数据，大概率让 Seconds_Behind_Master 一夜间跳到几小时——这不是网络问题，是设计问题。
为什么单条大 DELETE 会卡死从库 SQL 线程
从库的 SQL Thread（或 MTS 下的 worker）必须等整个事务提交后才更新 Exec_Master_Log_Pos，而一个删 50 万行的事务，在从库上就是连续执行 50 万次加锁 + 写 undo + 刷脏页 + 记 binlog（ROW 格式下每行一条事件）。期间：
- 其他事务全部排队等待
- SHOW PROCESSLIST 里长期显示 Updating 或 end
- Seconds_Behind_Master 不动或跳变失真（因计数更新滞后）
- 表空间不释放，后续 INSERT 触发页分裂，进一步拖慢回放
分批 DELETE 必须用 BETWEEN，别碰 LIMIT OFFSET
LIMIT 1000 OFFSET 10000 是高危写法：每次扫描都从头遍历索引树，越往后越慢；并发写入时 OFFSET 对应的范围还会漂移，导致漏删或重复删。
- 正确做法：基于有索引的单调字段（如自增
id）分段，例如WHERE id BETWEEN 100001 AND 200000 - 执行前先
EXPLAIN SELECT * FROM t WHERE id BETWEEN 100001 AND 200000，确认走索引；没命中就加索引，别硬扛 - 每批执行后显式
COMMIT，确保事务边界清晰、binlog 分段可并行 - 从库压力大时，可在每批后加
SLEEP(0.05)（非强制，但能缓解瞬时 I/O 和锁争用）
TRUNCATE TABLE 能不能直接替代 DELETE？
能，但前提极严：无外键引用该表、不需要保留自增 ID 值、接受不可回滚（哪怕在事务里执行也立即生效）。它快不是因为“优化了删除”，而是绕过了事务、undo、binlog（ROW 格式下不记录）、锁机制——直接释放数据段、重置 FSEG_HEADER、截断 .ibd 文件。
- 权限要求更高：
TRUNCATE需要DROP权限，而不仅是DELETE - MySQL 5.7+ 默认 ROW 格式下，
TRUNCATE不写行级 binlog，从库重放负担极小 - 分区表清空？
TRUNCATE TABLE t PARTITION (p1)仅 MySQL 8.0+ 支持，低版本不适用
从库端必须调的两个并行复制参数
光拆主库事务不够，从库不并行，照样卡在最后一步。MySQL 5.7+ 必须配：
-
slave_parallel_type = LOGICAL_CLOCK（推荐），启用基于组提交的并行回放 -
slave_parallel_workers = 8（建议设为从库 CPU 物理核心数的 75%～100%，不超过 16）
注意：slave_preserve_commit_order = ON 要配合开启，否则乱序提交可能破坏一致性；且主库需确保 binlog_format = ROW，STATEMENT 或 MIXED 下 MTS 效果受限。
真正卡住同步的从来不是吞吐量，而是单点阻塞。把一个“改完再提交”变成“改一点、提交、再改一点”，从库才能喘得上气。最易被忽略的是：事务拆分后没验证执行计划是否走索引，以及从库并行参数没开——这两点一漏，前面所有分批操作都白做。
