insert into select 不一定锁表，但在rr级别、无索引、大范围扫描时会因next-key锁导致等效锁表现象；根本优化路径是缩小扫描范围（加索引）和缩短锁持有时间（分批、降隔离级）。
MySQL 中 INSERT INTO SELECT 不一定“锁表”，但确实可能在特定条件下造成源表或目标表的严重锁竞争，甚至等效于锁表——尤其在 REPEATABLE READ 隔离级别、无合适索引、大范围扫描时。根本原因不是语句本身要锁整张表，而是它触发的锁类型（next-key lock）、锁粒度（行+间隙）和持续时间（整个语句执行期）叠加后，让其他事务“进不来”。读写分离和临时表是常见应对思路，但各自有明确适用边界和陷阱。
为什么 INSERT INTO SELECT 会卡住其他写操作
关键不在“插入”，而在“SELECT”部分的加锁行为：
- 在
REPEATABLE READ（默认）下，InnoDB 对源表S中被扫描到的每一行加 共享 next-key lock（行锁 + 间隙锁），防止幻读；这意味着其他事务想更新/删除这些行，或在间隙中插入新行，都会被阻塞 - 如果
WHERE条件没走索引，就会全表扫描 → 锁住源表几乎所有行和间隙 → 等效锁表 - 目标表
T上会加 意向排他锁（IX） 和实际插入行的 排他记录锁，但一般不导致大面积阻塞；真正拖慢全局的是源表锁 -
AUTO-INC锁也可能成为瓶颈：当目标表有自增主键，且innodb_autoinc_lock_mode = 1（默认）时，大批量插入会持有一个较重的表级自增锁，阻塞其他并发INSERT
读写分离能缓解吗？要看流量方向
读写分离对 INSERT INTO SELECT 引发的锁问题基本无效，甚至可能掩盖真实瓶颈：
- 它只把
SELECT流量路由到从库，但你的INSERT INTO SELECT是写语句，必须在主库执行 → 源表和目标表的锁依然发生在主库 - 如果从库也执行了该语句（比如误配了 binlog 复制规则），反而会因同步延迟或从库负载加重，放大问题
- 唯一能受益的场景是：你用从库做“只读分析”，而把
INSERT INTO SELECT改成先SELECT到应用层，再拼INSERT ... VALUES批量写入主库 —— 但这已脱离原语句范畴，且网络和应用层开销显著增加
用临时表替代 INSERT INTO SELECT 的实操要点
创建临时表（CREATE TEMPORARY TABLE ... AS SELECT）本身不解决锁源表的问题，但它把“锁源表”和“写目标表”两个动作拆开，为分批、降压、错峰提供操作空间：
-
CREATE TEMPORARY TABLE tmp AS SELECT ... FROM source WHERE ...这一步仍会对source加共享 next-key lock，但它是**单次、短时**的；完成后锁立刻释放，不影响后续业务 - 之后你可以用
INSERT INTO target SELECT ... FROM tmp LIMIT 1000分批次写入，每次只持目标表少量行锁，AUTO-INC锁也极短 - 临时表只在当前会话可见，无需清理元数据锁；但注意其内容不参与 binlog，不可复制
- 若源表极大且不能接受任何锁，可改用
SELECT ... INTO OUTFILE导出 CSV，再用LOAD DATA INFILE导入目标表 —— 这完全绕过源表加锁，但要求有文件系统权限且需额外运维步骤
真正有效的规避路径只有三条
所有方案都绕不开一个事实：InnoDB 在 RR 级别下为保证一致性，必须对扫描范围加锁。所以优化核心是“缩小扫描范围”和“缩短锁持有时间”：
- 强制走索引：确保
WHERE条件字段有高效索引，避免全表扫描；可用EXPLAIN验证type是否为range或ref，而非ALL - 降低隔离级别：将事务设为
READ COMMITTED，InnoDB 会对源表做 consistent read（不加锁），前提是 binlog_format 允许（非 STATEMENT 模式）且业务能接受 RC 级别的幻读风险 - 切片执行：用
LIMIT+ 偏移或基于自增主键分段（如id BETWEEN ? AND ?），配合循环或应用层调度，把单次 1000w 行变成 100 次 10w 行 —— 锁时间从分钟级降到秒级，业务几乎无感
最易被忽略的一点：哪怕用了临时表或分片，如果源表上没有合适的索引，第一步 SELECT 依然会扫全表、锁全表。索引设计永远是前置条件，不是可选项。
