面试题：INSERT...t...SELECT s会对s表加锁吗

前言：

insert into t2 select * from t1; 这条语句会对查询表 t1 加锁吗？不要轻易下结论。对GreatSQL的锁进行研究之前，首先要确认一下事务的隔离级别，不同的事务隔离级别，锁的表现是不一样的。

实验：

创建测试表t1，t2

创建存储过程，向t1表插入测试数据

REPEATABLE-READ隔离级别：

查询当前事务隔离级别：

connection 1：

connection2：

connection3：

connection1的语句中select的表t1上每条记录及最大伪记录supremum pseudo-record都加了S锁，这个S锁是nextkey lock锁，当connection2试图向t1表中插入一条表中不存在的数据时也会被阻塞，connect1的S锁与connect2需要的 X,GAP,INSERT_INTENTION锁不兼容。

在 REPEATABLE-READ 隔离级别下，INSERT ... SELECT 操作并未采用MVCC来保证事务一致性和隔离性，而是使用了锁机制。

加锁的目的是确保事务在读取数据时能够看到一个一致的数据快照。如果在执行 INSERT ... SELECT 时不加锁，那么可能会出现以下情况：

1. 不可重复读：如果在 INSERT ... SELECT 执行期间，另一个事务修改了被查询的数据，那么 INSERT ... SELECT 可能会读取到不同的数据，导致插入的数据不一致。
2. 幻读：在某些情况下，另一个事务可能会在 INSERT ... SELECT 执行期间插入新的行，导致插入操作插入到不应该插入的行。

通过加锁，InnoDB 能够确保 INSERT ... SELECT 语句在执行期间读取到的数据是一致的，并且不会被其他事务修改，从而维护了事务的隔离性和一致性。尽管 MVCC 可以在大多数情况下提供高效的数据读取和写入，但它并不能完全替代锁机制。在 INSERT ... SELECT 这样的操作中，使用 MVCC 可能无法提供足够的保证。

READ-COMMITTED隔离级别

查询当前事务隔离级别：

connection 1

connection 2

connection3

可以看出事务隔离级别设置为READ-COMMITTED后，表现截然不同。connection2并没有被阻塞，两个会话持有的锁都只有插入表意向排他锁(IX)。

结论：

INSERT...SELECT语句是否对查询表加锁跟事务隔离级别有关，REPEATABLE-READ隔离级别下加共享读锁，此共享读锁属于Nextkey lock，会影响其他事务对查询表的DML操作；READ-COMMITTED下不加锁，不影响其他事务对表进行DML操作。

Enjoy GreatSQL :)