虽然Insert语句不使用gap行锁，但是会使用一种叫插入意向锁的gap锁，即Insert Inrention Locks。这种锁的作用是为添加行锁做锁冲突检测，具体示例参考https://www.linuxidc.com/Linux/2018-04/151914.htm
的插入意向锁部分。
此外INSERT语句还涉及到主键的重复性检测，示例说明如下：
CREATE TABLE t1 (i INT, PRIMARY KEY (i)) ENGINE = InnoDB;
--会话A执行：
START TRANSACTION;
INSERT INTO t1 VALUES(1);
--会话B执行：
START TRANSACTION;
INSERT INTO t1 VALUES(1);
--会话C执行：
START TRANSACTION;
INSERT INTO t1 VALUES(1);
--最后会话A在执行：
ROLLBACK;
--最后发现会话B和C形成了死锁。
因为开始时会话A在i=1上添加了X模式的行锁，会话BC在做重复性检测时发现已有i=1,于是在各自请求行上的一个S行锁，当A会话rollback后，BC的S行锁都获取到了，此时B和C都需要把S行锁转化为X行锁，但是都不愿意放弃自己的S锁，而S和X是互斥的，因此形成死锁。这个问题其实和SQL Server的更新锁出现的原因一样，只不过SQL Server通过U锁解决了此问题，即重复性检测使用的是U锁，而U锁只能有一个会话获取。
8.INSERT ... ON DUPLICATE KEY UPDATE，这种插入语句和普通的INSERT语句区别在于，他会在发生重复性键值错误时向索引记录上添加X行锁，如果是主键那添加X模式的record lock行锁，如果是普通的唯一索引那添加X模式的next-key行锁。这姑且算是对7的死锁问题的一种解决办法吧。
9.REPLACE语句可以看做是INSERT ... ON DUPLICATE KEY UPDATE的简写。
10.INSERT INTO T SELECT ... FROM S WHERE ...语句会在T表的每个被插入的行上添加X模式的record lock（无gap锁）。
如果事务隔离级别被设置为READ COMMITTED，或者innodb_locks_unsafe_for_binlog设为1而且事物隔离级别不是SERIALIZABLE，那么这两种情况下InnoDB对S表执行一致性非锁定读。否则InnoDB会对S表上的每个行都添加S模式的next-key lock。
11.CREATE TABLE ... SELECT ...语句的加锁机制与INSERT INTO T SELECT ... FROM S WHERE ...完全一致。
REPLACE INTO t SELECT ... FROM s WHERE ...或者UPDATE t ... WHERE col IN (SELECT ... FROM s ...)这两种SQL语句对s表的行添加S模式的next-key行锁。
12.关于AUTO-INC Locks参考https://www.linuxidc.com/Linux/2018-04/151914.htm
的AUTO-INC Locks部分。
13.如果表上有外键约束，那么任何需要做外键约束检测的DML语句都会在相应的外键上添加S模式的行锁。即便约束失败也会设置这些行锁。
14.LOCK TABLES也会在表上设置表锁，只是这种表锁并非是InnoDB层的表锁，而是MySQL层的表锁。因此如果死锁涉及到这些表锁时，InnoDB的死锁自动检测机制无法检测到这些表锁。而且由于MySQL层对InnoDB层的行锁机制并不清楚，因此此类表锁甚至可以加在正在使用行锁的InnoDB表上。不过这并不会危及到事务的完整性，具体说明详见：https://dev.mysql.com/doc/refman/5.6/en/innodb-deadlock-detection.html