INSERT INTO SELECT 不一定锁全表，但在InnoDB的RR隔离级别下，若无索引导致全表扫描，会加大量next-key锁，等效锁表现象；优化需加索引、分批、降隔离级或用临时表。
INSERT INTO SELECT 会锁表吗？要看存储引擎和隔离级别
MySQL 中 INSERT INTO ... SELECT 在 InnoDB 下默认走当前读（current read），会对源表的扫描范围加临键锁（next-key lock），尤其在 REPEATABLE READ 隔离级别下容易阻塞其他事务。不是“全表锁”，但可能锁住大量索引区间，导致线上写入卡顿。
实操建议：
- 迁移前用
SELECT COUNT(*)和EXPLAIN确认扫描行数和是否走了索引；没走索引 = 锁更多、更慢、更危险 - 如果源表有主键或唯一索引，尽量在
WHERE条件中利用它做分批（比如id BETWEEN ? AND ?），避免全表扫描 - 临时调低隔离级别到
READ COMMITTED可减少锁范围，但需确认业务能容忍非重复读 - 避开高峰期执行；若必须在线迁移，优先考虑
pt-archiver或应用层流式拉取
怎么避免 “Duplicate entry” 导致整条 INSERT 失败？
INSERT INTO ... SELECT 是原子语句，只要其中一行违反主键/唯一约束，整个语句回滚——百万级数据里混进一条脏数据，就前功尽弃。
实操建议：
- 先用
SELECT COUNT(*) FROM source_table WHERE id IN (SELECT id FROM target_table)检查主键冲突存量 - 用
INSERT IGNORE INTO ... SELECT跳过冲突行（注意：MySQL 8.0.19+ 对IGNORE的语义有调整，部分警告不再抑制） - 更可控的方式是改用
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE id=id，空更新实现“去重插入” - 如需记录跳过的冲突行，得拆成两步：先
LEFT JOIN找出不存于目标表的记录，再插入
为什么加了 LIMIT 还报错 “This version of MySQL doesn’t yet support ‘LIMIT & IN/ALL/ANY/SOME subquery’”？
MySQL 5.7 及更早版本不支持在 INSERT INTO ... SELECT 的子查询里直接写 LIMIT，这是语法限制，不是性能问题。
实操建议：
- 用派生表绕过：
INSERT INTO t2 SELECT * FROM (SELECT * FROM t1 WHERE id > 1000000 ORDER BY id LIMIT 10000) AS tmp - 分批次时，别依赖子查询 LIMIT，改用主键范围切分，例如
WHERE id BETWEEN 1000001 AND 1010000 - 确认 MySQL 版本：8.0.20+ 已支持
LIMIT在子查询中使用，但生产环境仍建议用主键分片，更稳定可预期
INSERT INTO SELECT 比逐条 INSERT 快，但为什么还是慢？
快是相对的——它省去了网络往返和语句解析开销，但依然要走完整 SQL 执行流程：读源表、计算表达式、校验约束、写 binlog、刷 redo log。真正瓶颈常在 I/O 和锁竞争，而非语法本身。
实操建议：
- 关闭目标表的非必要索引（迁移完再重建），尤其是二级索引多时，写放大严重
- 确保
innodb_log_file_size足够大（建议 ≥ 1G），避免频繁 checkpoint 影响吞吐 - 批量大小控制在 1w–10w 行之间；太小起不到批量优势，太大易触发 long transaction 或 OOM
- 如果源表和目标表结构不同（比如字段类型转换、表达式计算），提前在应用层或临时表里处理好，别让 MySQL 边读边算
分批逻辑的边界条件、字符集隐式转换、timestamp 默认值行为——这些地方不报错，但数据可能悄悄歪掉。动手前，拿千条样本跑通全流程，比盲目冲百万级更重要。
