最稳妥的“移动”数据方式是分两步：先INSERT...SELECT插入目标表，再DELETE删除源表，全程用事务包裹。需显式列名、校验行数、检查约束兼容性，禁用TRUNCATE，避免主键冲突或数据丢失。
用 INSERT ... SELECT + DELETE 分两步最稳妥
直接“移动”在标准 SQL 中并不存在原子操作，必须拆成插入和删除两个步骤。先确保目标表结构兼容（列名、类型、约束），再执行插入；确认插入成功后，再删源数据。跳过校验或合并执行容易导致数据丢失或主键冲突。
-
INSERT INTO target_table (col1, col2) SELECT col1, col2 FROM source_table WHERE ...—— 显式列出字段，避免因表结构变动引发错位 - 执行前加
SELECT COUNT(*) FROM source_table WHERE ...记下待移动行数，插入后核对SELECT COUNT(*) FROM target_table WHERE ... - 不要依赖
INSERT ... SELECT的返回影响行数判断成败——某些驱动或事务隔离级别下可能不准
MySQL 中可用 INSERT ... SELECT 后接 DELETE 但需注意事务包裹
MySQL 不支持 TRUNCATE 跨库或带条件，也不允许在同一个语句中同时读写同一张源表（会报 ERROR 1093），所以不能用 DELETE 套子查询删自己。必须显式分步，并用事务保证一致性。
- 务必用
BEGIN; INSERT ... ; DELETE ... ; COMMIT;包裹，否则中途失败会导致数据残留或丢失 - 若目标表有自增主键，且需保留原 ID，插入时要显式指定该列（如
INSERT INTO t2(id, name) SELECT id, name FROM t1），否则新值会由 AUTO_INCREMENT 生成 - 外键约束启用时，
DELETE可能因子记录存在而失败，需提前检查或临时禁用（不推荐）
PostgreSQL 可用 WITH ... DELETE RETURNING 实现逻辑“移动”
PostgreSQL 支持在 DELETE 中用 RETURNING 获取被删行，再通过 CTE 插入目标表，看起来像原子移动，但本质仍是单事务内两操作，适合小到中等批量。
WITH moved AS ( DELETE FROM source_table WHERE status = 'archived' RETURNING id, name, created_at ) INSERT INTO archive_table (id, name, archived_at) SELECT id, name, created_at FROM moved;
-
RETURNING返回的是删除瞬间的快照，不会受并发修改影响 - 无法跨数据库执行；目标表字段类型必须兼容
RETURNING列，否则需显式转换（如created_at::TIMESTAMP） - 大数据量时不建议——
DELETE仍会触发索引更新和 WAL 写入，性能不比两步法好
千万别用 TRUNCATE + INSERT 替代移动
TRUNCATE 是 DDL 操作，不可回滚（在多数数据库中），且会重置自增计数器、忽略外键检查、可能需要更高权限。它清空整表，不支持 WHERE 条件，和“移动部分数据”目标根本冲突。
- 误写成
TRUNCATE source_table而非DELETE FROM source_table WHERE ...，会导致全表数据不可逆丢失 - 某些场景下
TRUNCATE会自动提交当前事务，导致前面的INSERT提前生效，破坏原子性 - 即使只移动全表，也应优先用
DELETE+ 显式事务，留出验证窗口
实际操作中最容易被忽略的是：没验证目标表的 NOT NULL、默认值、CHECK 约束是否与源数据兼容，导致 INSERT 静默失败或截断字段。动手前先跑一遍 INSERT ... SELECT 加 LIMIT 1，看是否报错。
