第三十九讲：insert句子的锁为什么这么多？

简概：

依旧是导言

​ 在上一篇文章中，我说到 MySQL 对自增主键锁做了优化，尽量在申请到自增 id 今后，就开释自增锁。因而，insert 句子是一个很轻量的操作。

​ 不过，这个定论关于“一般的 insert 句子”才有用。也就是说，还有些 insert 句子是归于“特殊情况”的，在履行过程中需求给其他资源加锁，或许无法在申请到自增 id 今后就立马开释自增锁。

​ 那么，今日这篇文章，咱们就一起来聊聊这个论题。insert … select 句子咱们先从昨日的问题说起吧。表 t 和 t2 的表结构、初始化数据句子如下，今日的比如咱们仍是针对这两个表打开。

CREATE TABLE `t` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `c` (`c`)
) ENGINE=InnoDB;

insert into t values(null, 1,1);
insert into t values(null, 2,2);
insert into t values(null, 3,3);
insert into t values(null, 4,4);

create table t2 like t

​ 现在，咱们一起来看看为什么在可重复读阻隔级别下，binlog_format=statement 时履行：

insert into t2(c,d) select c,d from t;

​ 这个句子时，需求对表 t 的一切行和空隙加锁呢？其实，这个问题咱们需求考虑的仍是日志和数据的一致性。咱们看下这个履行序列：