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。
