sql批量迁移应错峰分批、读写分离、实时校验：按ID或时间分片，每批5万~10万行，提交后暂停100ms；双写保障在线读写，预迁移至从库加速，监控主从延迟等指标并设回滚预案。
SQL批量数据迁移本身就会对业务产生压力，关键不是避免影响，而是把影响控制在可接受范围内。核心思路是：错峰迁移 + 分批处理 + 读写分离 + 实时校验。
分批次迁移，避免单次锁表或长事务
大表一次性迁移容易触发锁表、日志暴涨、主从延迟加剧。应按时间范围、ID区间或哈希分片切分数据。
- 用 WHERE id BETWEEN ? AND ? 拆分主键连续表，每次迁移5万~10万行
- 非主键表可用时间字段（如 created_at）分月/周迁移，确保增量数据可追平
- 每批提交后加短暂停顿（如 100ms），缓解主库压力和复制延迟
迁移期间保持业务可读可写
不中断服务的前提是迁移过程不影响线上增删改查。推荐双写+同步校验模式：
- 新老库同时写入（应用层或通过mysql触发器/Canal监听实现），确保数据不丢
- 迁移脚本只负责“补全历史数据”，不拦截或替换线上写入
- 切流前做最终比对：用 checksum 工具（如 pt-table-checksum）验证存量数据一致性
利用从库或离线环境预迁移
把耗时操作移出生产主库，大幅降低在线影响：
- 先在从库或备份实例上完成建表、索引、历史数据导入，再通过主从切换或dns切流上线
- 使用 LOAD DATA INFILE LOCAL 或 mysqldump –where 导出导入，比逐条INSERT快10倍以上
- 目标库提前开启并行复制（如 MySQL 8.0 的 WRITESET），加快追平速度
监控与回滚预案必须前置
没有监控的迁移等于蒙眼开车。重点盯住三项指标：
- 主从延迟（Seconds_Behind_Master）超过60秒立即暂停批次
- 主库 QPS 和慢查询数突增时，自动降级为单线程迁移
- 保留旧库至少72小时，所有新表加 READ ONLY=1 防误写，回滚只需切回原DNS或连接串
基本上就这些。不复杂但容易忽略的是节奏感——宁可多跑几轮小批次，也不要贪快压垮主库。