insert into ... select 比循环 insert 快，因其批量执行可合并写入、延迟索引更新、复用执行计划，并提升 i/o 与 cpu 利用率；需注意字段对齐、空值处理、主键冲突、分片策略及 binlog 格式等安全细节。
为什么 INSERT INTO ... SELECT 比循环 INSERT 快得多
因为单条 INSERT 带事务开销、日志刷盘、索引逐条更新；而 INSERT INTO ... SELECT 是批量执行，MySQL 可以合并写入、延迟索引更新、复用执行计划。尤其当源表数据已在内存或顺序读取时，I/O 和 CPU 利用率都更优。
常见错误现象：INSERT ... VALUES (...), (...), ... 拼几千行后执行仍卡顿，或触发 max_allowed_packet 报错；而用 SELECT 方式，哪怕源表有百万行，只要目标表结构兼容，一次就能推完。
- 必须确保目标表已存在，且字段顺序/类型能隐式兼容（否则加列别名或显式转换）
- 不带
WHERE的全表复制会锁源表（MyISAM）或产生大事务（InnoDB），建议分批次加条件过滤 - 如果目标表有自增主键，
INSERT INTO ... SELECT会正常分配新值，但不会复用源表的id——除非显式写出该字段
怎么写安全又高效的 INSERT INTO SELECT
核心是控制数据范围、避免锁表、绕过约束冲突。不是所有场景都能直接 “SELECT *” —— 字段对齐、NULL 允许性、默认值逻辑都得提前核对。
- 显式列出字段：用
INSERT INTO t1(col1, col2) SELECT s.colA, s.colB FROM src_table s WHERE ...，别依赖* - 处理空值：目标字段为
NOT NULL但源可能为NULL？补COALESCE(s.colA, 'default')或过滤掉 - 跳过重复主键/唯一键冲突：加
INSERT IGNORE INTO ...或ON DUPLICATE KEY UPDATE colX = VALUES(colX)（注意后者会触发更新逻辑） - 大表迁移时加
LIMIT+OFFSET不推荐（性能随 offset 增长暴跌），改用基于主键范围分片，例如WHERE id BETWEEN 10000 AND 19999
INSERT INTO SELECT 遇到 ERROR 1786 怎么办
这是 MySQL 5.7+ 开启 binlog_format=STATEMENT 时的典型报错：Statement is not safe to log in statement format。本质是某些函数（如 NOW()、UUID()、子查询含 LIMIT）在语句级复制下无法保证从库一致性。
- 最稳妥解法：把 binlog 格式切到
ROW（SET GLOBAL binlog_format = 'ROW'），重启会话再执行 - 临时绕过：避免在
SELECT中用非确定性函数；改用SYSDATE()不行，就用应用层传入固定时间戳 - 如果必须用
STATEMENT，且只是内部迁移无主从，可加SET SESSION sql_log_bin = 0（仅限测试环境！生产慎用）
目标表有外键或触发器时要注意什么
外键检查和触发器默认全程开启，会显著拖慢插入速度，甚至因逐行触发导致锁等待。
- 先关外键检查：
SET FOREIGN_KEY_CHECKS = 0，插完再= 1；注意确保数据引用关系本身是干净的 - 触发器无法禁用单个，只能临时删掉再重建（风险高）或确认触发逻辑是否真有必要在迁移时运行
- 如果目标表有全文索引，大量插入会导致索引重建卡顿，建议迁移前
ALTER TABLE t DROP INDEX ft_idx，插完再加回 - 记得检查
innodb_buffer_pool_size是否足够——太小会导致频繁刷脏页，反而让SELECT部分变慢
真正卡住的地方往往不在语法，而在没关外键、没调缓冲池、或者以为 SELECT * 能自动适配字段类型。跑之前多看一眼 SHOW CREATE TABLE 和 EXPLAIN 结果，比重试十次有用。
