根本原因是单事务体积过大导致SQL Thread串行阻塞、binlog事件堆积及从库随机IO与锁争用加剧；需分批删除、加索引、用分区或TRUNCATE替代。
大批量 DELETE 为什么会让从库同步脱节
根本原因不是 DELETE 本身，而是它在主从复制链路中触发的三重压力：单事务体积过大、SQL Thread 回放阻塞、以及 binlog 事件堆积。比如一个 DELETE FROM orders WHERE create_time 操作若影响 500 万行，在 ROW 格式 binlog 中会生成 500 万条前后镜像记录，从库 SQL Thread 必须串行回放——这期间 Seconds_Behind_Master 会持续飙升，且真实延迟远超该值显示（SBM 在大事务回放中“卡住不动”是已知缺陷）。
- 主库写入快，从库回放慢 → relay log 积压，IO Thread 被拖慢 → 新增查询请求打到从库时，数据还没落地
- 如果此时发生主库切换（如 MHA 触发），新主库可能缺失这批未回放的删除操作，导致数据不一致
- 更隐蔽的是：某些 ORM 或中间件会自动将带时间条件的 SELECT 路由到从库，而该从库尚未执行完删除，就会查到“本该已被删掉”的脏数据
用 LIMIT + 循环替代单条大 DELETE
这是最直接、兼容性最强的规避手段。核心是把一个巨型事务拆成多个小事务，控制每个事务影响行数在 1 万以内（具体阈值需结合从库回放能力压测确定），并确保每次提交后从库能及时追上。
- 避免使用
DELETE ... LIMIT N直接循环（易漏删或重复删），应基于自增主键或时间+ID 组合分段，例如：DELETE FROM orders WHERE id BETWEEN 1000001 AND 1010000 AND create_time - 每次执行后主动检查从库延迟：
SHOW REPLICA STATUS\G（MySQL 8.0.22+）或SHOW SLAVE STATUS\G，确认Seconds_Behind_Master≤ 5 秒再进行下一批 - 加
SLEEP(0.1)或更长间隔（如 0.5 秒），给从库留出回放缓冲窗口，尤其当从库配置低于主库时
从库启用 parallel_applier 配置加速回放
MySQL 5.7+ 支持多线程回放（MTS），但默认只对不同 database 的事务并发，对单表大批量操作无效。必须显式开启基于逻辑时钟（LOGICAL_CLOCK）的并行策略，才能让同一库内不同分区/不同行的 DELETE 并行回放。
- 主库需设置：
binlog_transaction_dependency_tracking = WRITESET（推荐）或COMMIT_ORDER - 从库需设置：
slave_parallel_type = LOGICAL_CLOCK和slave_parallel_workers = 4（根据 CPU 核数调整） - 验证是否生效：执行后查
SHOW PROCESSLIST，应看到多个Worker线程处于Slave_worker状态，而非仅一个SQL_Thread - 注意：启用
WRITESET后主库 binlog 体积略增（记录写集哈希），但换来的是从库回放速度提升 3–5 倍，对高延迟场景收益显著
业务层绕过从库读取刚删除的数据
即使做了上述优化，从库仍存在秒级延迟。真正杜绝“查到已删数据”，必须在应用侧做一致性兜底，不能依赖数据库自动同步完成。
- 对刚执行过 DELETE 的关键业务 ID（如用户 ID、订单号），后续相关 SELECT 强制走主库，可用注释标记：
/* FORCE_MASTER */ SELECT * FROM orders WHERE user_id = 123; - 引入轻量缓存层（如 Redis），在 DELETE 执行成功后立即
DEL order:123，查询时先查缓存再查库，避免穿透到延迟从库 - 若使用 ShardingSphere、MyCat 等中间件，配置
hint或sql-hint路由策略，对特定 DELETE 关联的查询动态切主
批量 DELETE 不是性能问题，是数据可见性问题。所有技术手段都只能压缩延迟窗口，无法彻底消除。真正可靠的方案，永远是应用层主动识别“刚删”场景，并绕过从库——这点最容易被忽略，也最常在线上引发客诉。
