用 insert into ... select + delete 分两步、带 limit 分批、每步查 row_count()，比游标循环快 10 倍以上，且事务可控、状态可验；因游标逐行处理导致 cpu 和锁开销陡增，而集合操作具备天然原子性与事务边界。
直接上结论：用 INSERT INTO ... SELECT + DELETE 分两步、带 LIMIT 分批、每步查 ROW_COUNT()，比游标循环快 10 倍以上，且事务可控、状态可验。
为什么别用游标做历史数据迁移
游标在 MySQL/SQL Server/PostgreSQL 中都属于「逐行处理」机制，本质是把集合操作退化为迭代——哪怕只是迁移 10 万行，也要执行 10 万次 FETCH + INSERT，CPU 和锁开销陡增。实测中，相同条件下游标耗时通常是 INSERT ... SELECT 的 8–12 倍，且容易触发 innodb_lock_wait_timeout 或 SQL Server 的阻塞等待。
更关键的是：游标内部无法天然保证原子性。比如插入成功但删除失败，或中途被 kill，残留状态极难清理。而集合操作天然具备「全成功或全失败」的事务边界（只要包在事务里）。
- MySQL 游标不支持动态 LIMIT，分批逻辑要自己写 WHILE 循环+变量控制，易出错
- SQL Server 游标默认是
STATIC，会先生成结果集快照，大表迁移时 tempdb 瞬间暴涨 - PostgreSQL 游标需显式
FETCH，配合pg_cron调度时超时风险高（默认 60 秒）
INSERT ... SELECT + DELETE 必须分两步执行
归档不是「删完再插」，也不是「插完就删」，而是「插稳了再删」。一步完成（如 INSERT INTO cold SELECT * FROM prod WHERE ...; DELETE FROM prod WHERE ...）看似简洁，但一旦中间出错（如目标表字段类型不匹配、字符集冲突、max_allowed_packet 超限），整个事务卡死，源表还被锁着。
分两步的核心价值是「解耦验证点」：
- 第一步：
INSERT INTO cold_db.orders_archive SELECT * FROM prod_db.orders WHERE create_time ，执行后立刻查 <code>SELECT ROW_COUNT()，确认是否真插了 10000 行；若为 0，说明没数据可搬，直接退出 - 第二步：仅当第一步返回值匹配预期，才执行
DELETE FROM prod_db.orders WHERE create_time ，同样用 <code>ROW_COUNT()校验删得准不准 - 两步之间加
SELECT SLEEP(0.1)（MySQL）或WAITFOR DELAY '00:00:00.1'（SQL Server）可缓解主从延迟导致的误判
存储过程里必须显式加事务和错误捕获
MySQL 存储过程默认自动提交（autocommit=1），SQL Server 默认每个语句自成事务，PostgreSQL 要求显式 BEGIN。不加控制，INSERT 成功但 DELETE 失败，就留下脏数据。
正确写法是：开头 START TRANSACTION（MySQL）、BEGIN TRY ... BEGIN CATCH（SQL Server）、BEGIN + EXCEPTION（PostgreSQL），且错误处理必须覆盖具体错误码：
- MySQL：用
DECLARE EXIT HANDLER FOR SQLSTATE '45000'捕获自定义异常，或FOR SQLEXCEPTION捕获所有 - SQL Server：在
CATCH块里用ERROR_NUMBER()判断是否是死锁（1205）或违反约束（547），区分重试还是告警 - PostgreSQL：避免用
RAISE EXCEPTION直接中断，优先GET STACKED DIAGNOSTICS记录上下文，再ROLLBACK - 所有平台都禁止依赖
@@ERROR或SQLCODE——它们只反映上一条语句，多语句下不可靠
冷备库表结构一致性常被忽略的三个细节
即使字段名、类型、长度都一样，以下三点不一致，INSERT ... SELECT 仍会静默失败或数据错乱：
-
TIMESTAMP字段：MySQL 默认随系统时区变化，DATETIME不变；若源库用TIMESTAMP记录创建时间，冷备库建表时没设DEFAULT CURRENT_TIMESTAMP，插入时该字段可能变 NULL 或被强制转成 UTC - 字符集与排序规则：源表用
utf8mb4_unicode_ci，冷备表用utf8mb4_general_ci，中文搜索结果可能不一致；更隐蔽的是COLLATE utf8mb4_0900_as_cs（大小写敏感）和_ai_ci（不区分重音）混用，导致唯一索引冲突 - 默认值行为差异：PostgreSQL 对
NOT NULL字段未指定默认值时拒绝插入；SQL Server 允许空字符串插入到NOT NULL VARCHAR字段；MySQL 5.7 严格模式下会报错，8.0 默认开启严格模式
最稳妥的做法：用 SHOW CREATE TABLE（MySQL）、sp_help（SQL Server）、\d+（psql）导出源表 DDL，逐行比对冷备表，尤其盯住 DEFAULT、COLLATE、ON UPDATE 这三处。
