INSERT INTO SELECT在源表上加的是意向排他锁（IX锁）而非共享锁（S锁），IX是InnoDB自动加的表级意向锁，用于声明将对某些行加X锁，不阻塞并发读但会阻塞源表的UPDATE、DELETE及DDL操作。
INSERT INTO SELECT 本身不会持有共享锁（S锁），它在源表上加的是意向排他锁（IX锁）——这是最关键的误判点。很多同学看到“只读不写却阻塞了UPDATE”，就以为是S锁搞的鬼，其实根本不是。
INSERT INTO SELECT 在源表上加的是 IX 锁，不是 S 锁
- InnoDB 把
INSERT INTO SELECT当作一个原子写操作：既要读源表（SELECT部分），又要写目标表（INSERT部分）。 - 为防止其他事务在你读的过程中对源表执行
DROP TABLE、ALTER TABLE或加 X 锁（比如UPDATE ... WHERE），InnoDB 必须提前声明意图——于是自动在源表加 IX 锁。 - IX 是表级意向锁，不阻塞并发读（SELECT 不加锁或只加 IS），但会阻塞其他事务对源表加 X 锁或 DDL，因为 IX 和 X / 表级 X 冲突。
常见错误现象：
-
SHOW ENGINE INNODB STATUS中看到trx_state = LOCK WAIT，等待锁类型是TABLE LOCK，且锁模式为IX - 源表上的
UPDATE突然变慢甚至超时，而SELECT仍正常 -
INFORMATION_SCHEMA.INNODB_TRX显示事务长时间运行，TRX_ROWS_LOCKED持续上涨
为什么有人误以为是“共享锁”？
- 因为
SELECT单独执行时默认加 IS（意向共享）或不加锁（RC 隔离级），而INSERT INTO SELECT的 SELECT 部分看起来“只是读”，直觉上该轻量。 - 实际上，它的锁强度由整个语句的语义决定，不是由 SELECT 子句单独决定。
- 如果你手动写
SELECT ... LOCK IN SHARE MODE，那才是真 S 锁；但INSERT INTO SELECT从不加 S 锁，也不需要你显式加。
关键区别：
-
SELECT ... LOCK IN SHARE MODE→ 加 S 锁 → 允许多个事务同时读，但后续UPDATE易死锁 -
INSERT INTO SELECT→ 加 IX 锁 → 不影响其他 SELECT，但会挡住源表上的 UPDATE / DELETE / DDL
如何验证当前加的是 IX 而不是 S？
用以下查询确认锁类型：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query, p.lock_mode, p.lock_type, p.lock_table, p.lock_index FROM information_schema.INNODB_LOCK_WAITS w JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id JOIN information_schema.INNODB_LOCKS p ON p.lock_trx_id = b.trx_id;
重点关注 p.lock_mode 字段：如果是 IX，就坐实了是意向排他锁；若出现 S，那一定是其他语句（比如你手写的 LOCK IN SHARE MODE）导致的。
真正容易被忽略的地方是：IX 锁的持续时间 = SELECT 扫描完成时间，而不是语句开始或结束时刻。扫描越慢（比如没走索引、全表扫千万行），IX 锁就挂得越久——这期间所有想改源表的事务都在排队等。优化索引、缩小扫描范围、或者干脆拆成应用层拉取 + 批量 INSERT VALUES，比纠结“是不是共享锁”实在得多。
