INSERT INTO ... SELECT 会卡死从库，因其在从库由单个SQL Thread串行执行，期间Seconds_Behind_Master不更新、新binlog排队积压，导致延迟骤升数十秒至数小时，且耗时取决于数据量与索引效率，与网络无关。
大事务是主从延迟最顽固的成因，单纯调参或升硬件无法根治——必须拆分事务逻辑，让每批执行可控、可监控、可回滚。
为什么 INSERT INTO ... SELECT 会卡死从库？
这类语句在从库由单个 SQL Thread 全量执行，期间 Seconds_Behind_Master 不更新，监控失灵；主库产生的新 binlog 全部排队等待，延迟瞬间跳变几十秒甚至数小时。
- 执行耗时取决于数据量+索引效率，而非网络或磁盘——即使万兆内网也无改善
-
OFFSET分页拆分会漏数据（源表并发写入时COUNT(*)和实际行不一致） - 用时间字段做范围条件，若源表该字段无索引或存在 NULL，容易全表扫描+锁表
如何安全拆分 INSERT INTO ... SELECT 大事务？
核心原则：按主键/自增 ID 分段，确保范围不重叠、全覆盖、可快速定位。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 每批次控制在
5000–10000行，目标单次执行 ≤ 2 秒（可通过EXPLAIN验证是否走索引） - 务必在源表和目标表上对分段字段（如
id）建有高效索引，否则每批 INSERT 可能因排序或锁升级变慢 - 使用
BETWEEN而非LIMIT，避免因并发写入导致数据遗漏或重复 - 每批独立
COMMIT，中间可加SLEEP(0.1)缓冲从库压力（非必需，视负载而定）
示例片段（MySQL 存储过程逻辑）：
UPDATE
- 强制走索引：先用
EXPLAIN确认执行计划，没命中就加索引或改写条件（例如把WHERE status=0改为WHERE status=0 AND id > ?） - 分批加
LIMIT：如UPDATE t SET status=1 WHERE status=0 ORDER BY id LIMIT 5000，循环直到ROW_COUNT() = 0 - 禁用
binlog_format = STATEMENT下的大范围 DML——它可能在从库因函数、临时表等执行失败或更慢 - 避开高峰期执行，尤其不要在从库承担读流量时运行
最容易被忽略的一点：拆分逻辑必须和业务一致性对齐。比如迁移用户订单时，不能只按 id 拆，还要确保同一用户的多条记录不被跨批次分散——否则从库查中间状态会看到“半完成”数据。这种场景需结合业务主键设计（如 user_id + order_id）做复合分段。
