Insert into Select 默认加 IX 锁，是因为 InnoDB 将其视为原子写操作，需在源表加意向排他锁以防止其他事务执行 DDL 或加 X 锁，避免读写冲突；IX 锁持有时间取决于 SELECT 扫描范围和时长，可通过索引优化、分批处理、READ COMMITTED 隔离级或分离读写（如 INTO OUTFILE + LOAD DATA）缓解。
Insert into Select 为什么默认加 IX 锁？
因为 INSERT INTO ... SELECT 在 MySQL（尤其是 InnoDB）中被当作一个原子写操作处理：它既要读取源表（SELECT 部分），又要向目标表插入新行。InnoDB 为保证并发安全，会在源表上加 IX（意向排他锁），即使你只读不写——这是为了防止其他事务在你读的过程中对源表加 X 锁或执行 DDL，从而避免读写冲突升级成死锁或不一致。
常见错误现象：SHOW ENGINE INNODB STATUS 中看到大量 TABLE LOCK 等待，trx_state = LOCK WAIT，且等待锁类型是 IX；同时源表上的其他 UPDATE/DELETE 操作明显变慢甚至超时。
如何避免源表被 IX 锁长期阻塞？
核心思路是切断“读-写耦合”，让 SELECT 部分不参与事务的写锁范围。最直接有效的方式是显式分离读取与插入：
- 先用
SELECT ... INTO @var或应用层拉取数据（如 Python 的cursor.fetchall()），再拼INSERT VALUES批量插入——这样源表只持IS（意向共享）锁，且持续时间极短 - 如果必须用
INSERT INTO ... SELECT，确保源表有合适索引，避免全表扫描——扫描越久，IX锁持有时间越长 - 在事务中显式给源表加
LOCK IN SHARE MODE（仅当业务允许读一致性降级为 RC 级别时），可让后续读更轻量，但注意这会阻止源表上的UPDATE
示例（安全替代）：
SELECT id, name, status FROM orders WHERE created_at > '2026-06-01' INTO OUTFILE '/tmp/batch_data.csv' FIELDS TERMINATED BY ',';
再用 LOAD DATA INFILE 导入目标表——绕过事务锁链。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
innodb_lock_wait_timeout 和 read_committed_snapshot 有影响吗？
没有直接影响。innodb_lock_wait_timeout 只控制等待锁的超时时间，不改变 IX 锁本身的行为；而 read_committed_snapshot 是 SQL Server 的概念，MySQL 中对应的是 READ COMMITTED 隔离级别 + 多版本并发控制（MVCC），它能让 SELECT 不加锁（快照读），但 INSERT INTO ... SELECT 是特殊语句——即使在 READ COMMITTED 下，InnoDB 仍会对源表加 IX 锁，因为插入动作本身需要确保源数据在读期间不被破坏性修改。
真正起作用的配置只有：transaction_isolation = READ-COMMITTED（减少间隙锁）、innodb_autoinc_lock_mode = 2（提升目标表自增性能，间接缓解锁竞争）。
分区表 or 并行拆分能缓解吗？
能，但要注意适用边界：
- 如果源表按时间/ID 分区，且
SELECT条件能命中单个分区（如WHERE dt = '2026-06-15'），InnoDB 只对实际访问的分区加IX锁，而非整张表 - 手动拆成多个小
INSERT INTO ... SELECT（如每 1w 行一批），配合COMMIT，可显著缩短单次锁持有时间——但要注意避免频繁小事务导致 binlog 膨胀和主从延迟 - 不要依赖
parallel query（MySQL 8.2+ 实验特性），它对INSERT ... SELECT的并行支持有限，且可能加剧锁争用
最容易被忽略的一点：INSERT INTO ... SELECT 的目标表如果有触发器、外键约束或唯一索引校验，也会延长事务时间，间接拉长源表 IX 锁持有窗口——上线前务必检查目标表结构是否“轻量化”。
