INSERT INTO SELECT 是否锁全表取决于存储引擎和隔离级别：InnoDB 默认一致性读不锁源表，但无索引扫描可能触发间隙锁；MyISAM 直接表级读锁；STATEMENT 格式要求确定性，否则报错，推荐改用 ROW 格式。
INSERT INTO SELECT 会锁全表吗？取决于存储引擎和隔离级别
在 InnoDB 下，INSERT INTO ... SELECT 默认不会锁源表（SELECT 部分）的全表，但行为受事务隔离级别和查询是否走索引影响：
- READ COMMITTED 或 REPEATABLE READ 下，源表上加的是**一致性读（consistent read）**，不加锁，除非显式加 FOR UPDATE 或 LOCK IN SHARE MODE；
- 如果 SELECT 扫描无索引字段或使用 WHERE 条件命中率低，可能触发大量间隙锁或临键锁（尤其在 REPEATABLE READ）；
- MyISAM 会直接对源表加**表级读锁**，阻塞所有写操作，复制大表时务必避免。
binlog_format = STATEMENT 会导致 INSERT INTO SELECT 失败
当 binlog_format = STATEMENT 时，MySQL 要求 SELECT 子句必须是**确定性（deterministic）** 的，否则主从不一致风险高，会直接报错：
- 常见触发场景：含 UUID()、NOW()、RAND()、用户变量（@var）、子查询中含非确定函数；
- 错误信息形如：ERROR 1665 (HY000): Cannot execute statement: binlogging impossible since the statement is non-deterministic；
- 解决方式不是改 SQL，而是切换为 binlog_format = ROW（推荐）或 MIXED —— ROW 模式下只记录行变更，完全绕过确定性校验。
大表复制卡顿、OOM 或主从延迟的常见诱因
即使语法合法、锁也可控，实际执行仍可能崩：
- INSERT INTO ... SELECT 是单事务操作，若复制 1 亿行，事务日志（innodb_log_file_size）、回滚段（innodb_undo_log_truncate）和内存（sort_buffer_size、join_buffer_size）都可能被撑爆；
- ROW 格式 binlog 体积激增，尤其更新宽表或含大字段（TEXT/BLOB），主库磁盘 IO 和网络带宽易成瓶颈；
- 从库重放时，单事务无法并行（即使开了 slave_parallel_type = LOGICAL_CLOCK），导致严重延迟；
- 更稳妥的做法是拆成小批次：INSERT INTO ... SELECT ... WHERE id BETWEEN ? AND ?，配合 ORDER BY id 和自增主键分片。
替代方案比硬扛 INSERT INTO SELECT 更可靠
真正处理 TB 级数据迁移时，原生命令往往不是最优解：
- 使用 mysqldump --single-transaction --skip-triggers --no-create-info 导出 + mysqlimport 或 LOAD DATA INFILE，支持分块、压缩、跳过约束检查；
- 对在线业务，优先考虑 pt-archiver：自动分批、限速、支持 --where 过滤、可干掉源表旧数据；
- 若目标是构建新表结构，用 CREATE TABLE ... AS SELECT 更轻量（不走 binlog 写入逻辑，但注意它不复制索引/约束/注释）；
- 所有方案上线前，务必在从库或测试实例跑 EXPLAIN FORMAT=JSON 看执行计划，确认 SELECT 部分走了索引且没有 Using temporary / Using filesort。
真正难的不是写出能跑的语句，而是预判它在 200GB 表、从库延迟已到 3 小时、DBA 正在查慢日志时的表现。锁和 binlog 只是表象，背后是事务粒度、IO 路径和复制拓扑的耦合。
