INSERT INTO ... SELECT 是跨表批量迁移最常用高效方式，需确保字段数量、类型、顺序匹配或显式指定列名，配合事务、分批处理及错误处理机制保障安全与性能。
INSERT INTO ... SELECT 一次性迁移数据
直接用 INSERT INTO target_table SELECT ... FROM source_table 是最常用的方式，前提是两张表字段数量、类型、顺序能对齐，或者你显式指定列名。别指望数据库自动帮你做类型转换——比如把字符串插入到 INT 字段会报错，哪怕内容看着像数字。
实操建议：
- 先写
SELECT部分单独执行，确认返回结果的列数、顺序、值是否符合目标表要求 - 如果字段名不一致或需加工，必须显式写出列名，例如：
INSERT INTO users (name, age) SELECT full_name, CAST(age_str AS INTEGER) FROM legacy_users - 注意
NOT NULL约束：源表某列为NULL，但目标表对应列不允许为空，就会中断整个语句 - 大表迁移前加
WHERE 1=0测试语法，避免误插全量数据
处理主键冲突：ON CONFLICT 或 IGNORE
目标表已有部分数据，又想跳过重复、只插入新记录？PostgreSQL 用 ON CONFLICT，MySQL 用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，SQL Server 用 MERGE。别混用语法，不同数据库根本不兼容。
常见错误现象：
- PostgreSQL 报错
duplicate key violates unique constraint，说明没加ON CONFLICT - MySQL 用
INSERT IGNORE后发现某些本该更新的字段没变，是因为它只忽略错误，不更新——此时该换ON DUPLICATE KEY UPDATE - SQLite 的
INSERT OR IGNORE不支持更新逻辑，纯跳过
示例（PostgreSQL）：INSERT INTO products SELECT * FROM staging_products ON CONFLICT (id) DO NOTHING
跨库/跨服务器迁移时字段映射容易出错
当源表和目标表不在同一个数据库，甚至不是同一种数据库系统（比如从 MySQL 迁到 PostgreSQL），字段类型映射是最大雷区。比如 MySQL 的 TINYINT(1) 常被用作布尔，但 PostgreSQL 没有等价的隐式转换；SQL Server 的 DATETIME2 精度高于 MySQL 的 DATETIME，直接插入可能截断毫秒。
使用场景判断：
- 如果是同构迁移（如 MySQL → MySQL），优先用
mysqldump --where+mysql命令行导入，比纯 SQL 更稳 - 异构迁移务必逐字段核对：用
SELECT DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM INFORMATION_SCHEMA.COLUMNS查源/目标表元数据 - 字符串长度超限、数值溢出、时区偏移（如
NOW()在不同时区服务器上结果不同）都是静默失败点，不能只看“执行成功”
大批量插入性能卡在单条 INSERT 上
用循环拼接几百条 INSERT INTO ... VALUES (...), (...), (...) 虽然可行，但一旦数据量过万，解析、网络传输、事务日志开销会急剧上升。真正的批量效率来自两点：减少语句数量 + 控制事务粒度。
实操建议：
- PostgreSQL / MySQL 8.0.19+ 支持多值
INSERT，一次最多塞 1000 行左右（具体看max_allowed_packet或work_mem） - 禁用自动提交，手动
BEGIN/COMMIT，每 5000–10000 行提交一次，避免长事务锁表 - 临时关闭目标表索引（仅限离线迁移）：PostgreSQL 可
SET LOCAL enable_indexscan = off，MySQL 可先DROP INDEX再重建 - 别依赖 ORM 的 save() 循环——那是为单条设计的，批量请绕过 ORM 直接走原生 SQL
复杂点往往不在语法，而在你没意识到源数据里藏着空字符串当日期、负数当无符号整型、或者 JSON 字段里混了未转义的双引号——这些都会让看似完整的 INSERT SELECT 在中途戛然而止。
