一、Record Lock：单个记录上的锁
Record Lock总是会锁住索引记录，如果InnoDB存储引擎表在建立的时候没有设置任何一个索引，那么这时InnoDB存储引擎会使用隐式的主键来进行锁定。
二、Gap Lock：间隙锁
设计目的：是为了解决Phantom Problem（幻象/幻读），利用这种锁技术，锁定的不是单个值，而是一个范围。
三、Next-Key Lock：Gap Lock+Record Lock
Next-Key Lock是结合了Gap Lock和Record Lock的一种锁定算法，在此种算法下，InnoDB对于行的查询都是采用这种锁定算法。
例如：
有10、11、13、20这四个值，那么索引可能被Next-Key Locking的区间为：
1、（-∞，10]
2、（10，11]
3、（11，13]
4、（13，20]
5、（20，+∞）
除了Next-Key Locking，还有Previous-Key Locking，如上面的例子，可锁定的区间为：
1、（-∞，10）
2、 [10，11）
3、 [11，13）
4、 [13，20）
5、 [20，+∞）
然而，当查询的索引含有唯一属性时，InnoDB存储引擎对Next-Key Lock进行优化，将其降级为Record Lock，即仅锁住索引本身，而不是范围。如表中有1，2，5的id数据：
会话A首先对a=5进行X锁。而由于a是主键且唯一，因此锁定的仅是5这个值，而不是（2,5）的范围，这样在B中插入值4不会阻塞，可以立即插入并返回。即锁定由Next-Key Lock算法降级为Record Lock，从而提高了并发性。
Next-Key Lock降级为Record Lock仅在查询的列是唯一索引的情况下。
若是辅助索引，则情况会完全不同如：
CREATE TABLE z(a INT,b INT,PRIMARY KEY(a),KEY(b))
INSERT INTO z SELECT 1,1;
INSERT INTO z SELECT 3,1;
INSERT INTO z SELECT 5,3;
INSERT INTO z SELECT 7,6;
INSERT INTO z SELECT 10,8;
表z的b列是辅助索引，若在会话A中执行下面的SQL：
SELECT * FROM z WHERE b=3 FOR UPDATE;
这是Sql语句通过索引列b进行查询，因此其使用传统的Next-Key Locking加锁，并且由于两个索引，其需要分别进行锁定。对于聚集索引，其仅对a等于5的索引加上record Lock。对于辅助索引，其加上的是Next-Key Lock，锁定的范围是（1,3），需要注意的是，InnoDB存储引擎还会对辅助索引下一个键值加上gap lock，即还有一个辅助索引的范围为（1,6）的锁，因此，在B会话中运行下面的Sql语句，都会被阻塞：
SELECT * FORM z WHERE a=5 LOCK IN SHARE MODE;
INSERT INTO z SELECT 4,2;
INSERT INTO z SELECT 6,5;
而执行下面的语句，不会阻塞：
INSERT INTO z SELECT 8,6;
INSERT INTO z SELECT 2,0;
INSERT INTO z SELECT 6,7;
在默认的事务隔离级别下，即REPEATABLE READ下，InnoDB存储引擎采用Next-Key Locking机制来避免Phantom Problem（幻象问题）