InnoDB实现标准的行级锁定，其中有两种类型的锁，共享(S)锁和独占(X)锁。
如果事务在row上T1持有共享(S)锁r，则来自某个不同事务T2的对row锁的请求r将按如下方式处理：
如果事务在row上T1持有排他(X)锁，则无法立即授予r来自某个不同事务T2对任一类型锁的请求。r相反，事务T2必须等待事务T1释放其对row的锁定r。
InnoDB支持多粒度锁，允许行锁和表锁并存。例如，诸如在指定表上LOCKTABLES...WRITE获取排他锁（一个锁）的语句。X为了使多粒度级别的锁定变得切实可行，InnoDB请使用意向锁。意向锁是表级锁，指示事务稍后对表中的行需要哪种类型的锁（共享或独占）。意向锁有两种类型：
例如，SELECT...FORSHARE设置一个IS锁，并SELECT...FORUPDATE设置一个IX锁。
意向锁定协议如下：
下表总结了表级锁类型兼容性。
如果请求事务与现有锁兼容，则将锁授予请求事务，但如果它与现有锁冲突，则不会授予该锁。事务等待，直到释放冲突的现有锁。如果锁定请求与现有锁定冲突并且由于会导致死锁而无法授予，则会发生错误。
意向锁不会阻塞除全表请求（例如，LOCKTABLES...WRITE）之外的任何内容。意向锁的主要目的是表明有人正在锁定一行，或者将要锁定表中的一行。
意向锁的事务数据在InnoDB监视器输出SHOWENGINEINNODBSTATUS中类似于以下内容：
TABLELOCKtable`test`.`t`trxid10080lockmodeIX
记录锁是索引记录上的锁。例如，SELECTc1FROMtWHEREc1=10FORUPDATE;防止任何其他事务插入、更新或删除值为的t.c1行10。
记录锁总是锁定索引记录，即使表没有定义索引。对于这种情况，InnoDB创建一个隐藏的聚簇索引并使用该索引进行记录锁定。请参阅第15.6.2.1节，“聚簇索引和二级索引”。
记录锁的事务数据在InnoDB监视器输出SHOWENGINEINNODBSTATUS中类似于以下内容：
间隙锁是在索引记录之间的间隙上的锁，或者是在第一条索引记录之前或最后一条索引记录之后的间隙上的锁。例如，SELECTc1FROMtWHEREc1BETWEEN10and20FORUPDATE;阻止其他事务将值插入15到列t.c1中，无论该列中是否已经存在任何此类值，因为范围内所有现有值之间的间隙都已锁定。
间隙可能跨越单个索引值、多个索引值，甚至是空的。
间隙锁是性能和并发性之间权衡的一部分，并且用于某些事务隔离级别而不是其他事务隔离级别。
对于使用唯一索引锁定行以搜索唯一行的语句，不需要间隙锁定。（这不包括搜索条件只包括多列唯一索引的某些列的情况；在这种情况下，确实会发生间隙锁定。）例如，如果该id列具有唯一索引，则以下语句仅使用一个索引记录锁定id值为100的行，其他会话是否在前面的间隙中插入行并不重要：
SELECT*FROMchildWHEREid=100;如果id未索引或具有非唯一索引，则该语句会锁定前面的间隙。
这里还值得注意的是，不同事务可以在间隙上持有冲突锁。例如，事务A可以在一个间隙上持有一个共享间隙锁（间隙S锁），而事务B在同一间隙上持有一个独占间隙锁（间隙X锁）。允许冲突间隙锁的原因是，如果从索引中清除记录，则必须合并不同事务在记录上持有的间隙锁。
间隙锁InnoDB是“纯粹抑制性的”，这意味着它们的唯一目的是防止其他事务插入间隙。间隙锁可以共存。一个事务获取的间隙锁不会阻止另一个事务在同一间隙上获取间隙锁。共享和排他间隙锁之间没有区别。它们彼此不冲突，并且它们执行相同的功能。
可以明确禁用间隙锁定。如果您将事务隔离级别更改为，则会发生这种情况READCOMMITTED。在这种情况下，间隙锁定在搜索和索引扫描中被禁用，并且仅用于外键约束检查和重复键检查。
READCOMMITTED使用隔离级别还有其他影响。WHERE在MySQL评估条件后，释放不匹配行的记录锁。对于UPDATE语句，InnoDB进行“半一致”读取，这样它将最新提交的版本返回给MySQL，以便MySQL可以确定该行是否匹配WHERE.UPDATE
下一个键锁是索引记录上的记录锁和索引记录之前的间隙上的间隙锁的组合。
InnoDB执行行级锁定的方式是，当它搜索或扫描表索引时，它会在遇到的索引记录上设置共享或排他锁。因此，行级锁实际上是索引记录锁。索引记录上的下一个键锁也会影响该索引记录之前的“间隙”。也就是说，下一个键锁是索引记录锁加上索引记录之前的间隙上的间隙锁。如果一个会话在索引中的记录上具有共享锁或独占锁R，则另一个会话无法R在索引顺序之前的空隙中插入新的索引记录。
假设一个索引包含值10、11、13和20。该索引可能的next-key锁涵盖以下区间，其中圆括号表示排除区间端点，方括号表示包含端点：
默认情况下，InnoDB在REPEATABLEREAD事务隔离级别运行。在这种情况下，InnoDB使用下一个键锁进行搜索和索引扫描，以防止出现幻象行。
next-key锁的事务数据在InnoDB监视器输出SHOWENGINEINNODBSTATUS中类似于以下内容：
RECORDLOCKSspaceid58pageno3nbits72index`PRIMARY`oftable`test`.`t`trxid10080lock_modeXRecordlock,heapno1PHYSICALRECORD:n_fields1;compactformat;infobits00:len8;hex73757072656d756d;ascsupremum;;
插入意图锁是一种INSERT在行插入之前由操作设置的间隙锁。这个锁表示插入的意图，这样插入到同一个索引间隙中的多个事务如果没有插入到间隙中的相同位置，则不需要相互等待。假设有值为4和7的索引记录。分别尝试插入值5和6的单独事务，在获得对插入行的排他锁之前，每个事务都使用插入意向锁锁定4和7之间的间隙，但不要互相阻塞，因为这些行是不冲突的。
以下示例演示了一个事务在获取插入记录的独占锁之前获取插入意向锁。该示例涉及两个客户端A和B。
客户端A创建了一个包含两条索引记录（90和102）的表，然后启动一个事务，在ID大于100的索引记录上放置排他锁。排他锁包括记录102之前的间隙锁：
mysql>CREATETABLEchild(idint(11)NOTNULL,PRIMARYKEY(id))ENGINE=InnoDB;mysql>INSERTINTOchild(id)values(90),(102);mysql>STARTTRANSACTION;mysql>SELECT*FROMchildWHEREid>100FORUPDATE;+-----+|id|+-----+|102|+-----+客户端B开始事务以将记录插入间隙。事务在等待获得独占锁时获取插入意向锁。
mysql>STARTTRANSACTION;mysql>INSERTINTOchild(id)VALUES(101);插入意向锁的事务数据在InnoDB监视器输出SHOWENGINEINNODBSTATUS中类似于以下内容：
RECORDLOCKSspaceid31pageno3nbits72index`PRIMARY`oftable`test`.`child`trxid8731lock_modeXlocksgapbeforerecinsertintentionwaitingRecordlock,heapno3PHYSICALRECORD:n_fields3;compactformat;infobits00:len4;hex80000066;ascf;;1:len6;hex000000002215;asc";;2:len7;hex9000000172011c;ascr;;...
锁是一种AUTO-INC特殊的表级锁，由插入到具有AUTO_INCREMENT列的表中的事务获取。在最简单的情况下，如果一个事务正在向表中插入值，则任何其他事务必须等待自己向该表中插入，以便第一个事务插入的行接收连续的主键值。
该innodb_autoinc_lock_mode变量控制用于自动增量锁定的算法。它允许您选择如何在可预测的自动增量值序列和插入操作的最大并发性之间进行权衡。
为了处理涉及SPATIAL索引的操作的锁定，下一个键锁定不能很好地支持REPEATABLEREAD或SERIALIZABLE事务隔离级别。多维数据没有绝对排序的概念，所以不清楚哪个是“next”键。
SPATIAL要启用对带索引的表的隔离级别的支持，请使用谓词锁。索引包含SPATIAL最小边界矩形(MBR)值，因此InnoDB通过在用于查询的MBR值上设置谓词锁来强制对索引进行一致读取。其他事务无法插入或修改与查询条件匹配的行。