INSERT INTO select 比循环 INSERT 快，因其为单次语句执行，仅需一次解析和事务日志写入，减少网络往返与调度延迟；字段数、顺序、类型须严格匹配，推荐显式指定目标字段；大表操作需按主键或时间分段控制批量大小以防锁表或内存溢出。
INSERT INTO SELECT 为什么比循环 INSERT 快
因为整条 INSERT INTO ... SELECT 是单次语句执行，mysql 只需一次解析、一次事务日志写入（在 AUTOCOMMIT=1 下仍比多条 INSERT 少开销），避免了网络往返和客户端循环调度的延迟。尤其当源表数据量大、目标表有索引或外键时，批量查插的性能优势更明显。
语法结构与必须注意的字段匹配规则
目标表字段数、顺序、类型兼容性必须与 SELECT 的结果列严格对应，否则报错 column count doesn't match value count at row 1 或类型隐式转换失败。不建议依赖列名自动映射 —— 即使字段名相同，只要顺序不对就会出错。
- 显式写出目标字段，例如：
INSERT INTO t2 (id, name, created_at) SELECT id, username, NOW() FROM t1 WHERE status = 'active' - 避免省略字段列表，如
INSERT INTO t2 SELECT ...—— 表结构一旦变更（比如加了NOT NULL新字段），语句立即失效 -
SELECT中可用常量、函数（如NOW()、UUID()）、表达式，但不能引用目标表别名（MySQL 不支持INSERT ... SELECT中对目标表的自关联）
如何控制批量大小防止锁表或内存溢出
大表全量复制容易触发长事务、MDL 锁阻塞 DDL，或因临时排序/缓冲区不足导致 Error 1038 (HY001): Out of sort memory。MySQL 没有内置的 LIMIT 分页插入语法，需手动分片。
- 用主键/自增 ID 分段：例如每次取
WHERE id BETWEEN 10000 AND 19999，配合ORDER BY id确保顺序 - 用时间字段分段更稳定（如果业务有更新时间）：
WHERE updated_at >= '2024-01-01' AND updated_at - 每批控制在 1w–5w 行较安全；可通过
SELECT COUNT(*)预估再拆分，避免单次语句超max_allowed_packet
INSERT INTO orders_archive (order_id, user_id, amount, archived_at) SELECT order_id, user_id, amount, NOW() FROM orders WHERE order_id BETWEEN 100000 AND 109999 AND status = 'completed';常见错误和绕过限制的方法
遇到 ERROR 1786 (HY000): Statement violates GTID consistency，说明启用了 GTID 且语句含不确定函数（如 RAND()、UUID()、NOW()）。这不是 bug，是 MySQL 的强一致性保护。
- 方案一：关闭 GTID（不推荐生产环境）
- 方案二：改用确定性时间值，例如
FROM_unixTIME(UNIX_TIMESTAMP() - 3600)替代NOW()（前提是精度可接受） - 方案三：先
SELECT ... INTO OUTFILE导出，再LOAD DATA INFILE（绕过 GTID 限制，但需文件权限） - 注意：若目标表有唯一键冲突，默认行为是中断整个语句；加
INSERT IGNORE或ON DUPLICATE KEY UPDATE可处理，但后者在SELECT场景下写法稍复杂
跨库插入时，确保用户有源表 SELECT 权限和目标表 INSERT 权限 —— 权限检查是分开做的，少一个都会报 ERROR 1142。