最稳妥的数据迁移方式是insert...select先复制再删除。需预先建好结构一致的备份表，显式指定字段避免自增id冲突，务必加where条件并验证数量，大表操作应选低峰期，insert与delete必须在同一事务中执行。
用 INSERT ... SELECT 实现数据迁移
直接把源表符合条件的数据插入备份表，是最常用也最稳妥的方式。关键不是“移动”，而是“先复制再删除”，避免误操作丢失数据。
- 备份表必须预先创建，结构需与源表一致（或至少包含目标字段），否则
INSERT ... SELECT会报错：Column count doesn't match value count - 如果备份表有自增主键，而你想保留原记录的 ID，记得在
INSERT中显式列出字段，不要用*；否则可能触发新自增值 - 执行前务必加
WHERE条件，并先用SELECT COUNT(*) FROM source_table WHERE ...确认数量——漏写条件会导致整表被搬走 - 大表操作建议加
LOW_PRIORITY或在业务低峰期执行，避免长时间锁表（尤其是 MyISAM）
DELETE 配合事务确保原子性
复制完成后删源数据，必须和前面的 INSERT 放在同一事务里，否则中间出错会导致数据不一致。
- 不要分开执行两条语句，必须包裹在
BEGIN; ... COMMIT;中 - 示例：
BEGIN; INSERT INTO backup_table SELECT * FROM source_table WHERE created_at
- 如果备份表有唯一约束或外键，而源数据存在冲突，
INSERT会失败，事务自动回滚，DELETE不会执行——这是你想要的安全机制 - 注意：InnoDB 支持行级锁，但
DELETE的 WHERE 条件若未命中索引，仍可能升级为表锁
用 CREATE TABLE ... AS SELECT 快速建备份表（仅限一次性）
如果备份表还不存在，且你只要某一部分数据的快照，可以用这条语句一步到位建表+填充数据。
CREATE TABLE backup_table AS SELECT * FROM source_table WHERE created_at —— 这条语句不会复制索引、主键、AUTO_INCREMENT 属性，只复制数据和字段定义- 后续必须手动添加主键：
ALTER TABLE backup_table ADD PRIMARY KEY (id);，否则无法高效查询或关联 - 该语句隐式开启事务，但不支持在同一个语句里同时指定表选项（如
ENGINE=InnoDB），需要额外ALTER TABLE补充 - 不适合用于增量备份场景，因为每次执行都会重建整张表
避免使用 RENAME TABLE + INSERT 的“伪移动”方案
有人想用 RENAME TABLE 换表名，再补数据，这容易引发权限、视图、存储过程失效等问题，不是真正的数据移动。
-
RENAME TABLE source_table TO old_table, backup_table TO source_table;看似快，但原source_table的触发器、外键引用、应用连接池里的预编译 SQL 全部失效 - 如果备份表是分区表或带压缩选项，
RENAME后这些属性不会继承过去 - 真正要“移动”，就老老实实走
INSERT ... SELECT + DELETE，别贪快绕开数据一致性校验
实际执行时，最容易被忽略的是备份表的字符集和排序规则是否与源表完全一致——哪怕只是 utf8mb4_0900_as_cs 和 utf8mb4_0900_ai_ci 的差异，都可能导致 INSERT 因隐式转换失败或乱码。动手前先查 SHOW CREATE TABLE source_table; 对比两表 DDL。
