标签：矩阵 inno 事务隔离级别 esc 级别 一个 避免 通过 vertica
官方文档：InnoDB Locking and Transaction Model
InnoDB存储引擎实现了两种标准的行级锁：
如果事务T1在行r上持有共享锁，另外的事务T2在行r上的请求锁，则会得到如下处理：
如果事务T1在行r上持有排它锁，另一事务T2在行r上的请求任何类型的锁都不会立即授予，T2必须等待T1释放行r上的锁。
InnoDB存储引擎支持多粒度锁定，即允许行锁和表锁同时存在。为了支持这种多粒度锁定，InnoDB存储引擎使用了意向锁(Intention Lock)。意向锁是将锁定的对象分为多个层次，意味着事务希望在更细粒度上进行加锁。意向锁是表级别的锁，用于指定事务稍后对表中的行需要哪种锁类型(共享锁或排它锁)。有两种类型的意向锁：
IS)：表示事务打算对表中的各行设置共享锁IX)：表示事务打算对表中的各行设置排它锁例如：
SELECT ... LOCK IN SHARE MODE 会设置一个意向共享锁(IS) SELECT ... FOR UPDATE 会设置一个意向排它锁(IX)
意向锁协议如下：
如果锁与现有锁兼容，则将其授予请求的事务，但如果与现有锁冲突，则不授予锁。 事务会等待直到冲突的现有锁被释放。意向锁的主要目的是表明有人正在锁定表中的行，或者打算锁定表中的行。
InnoDB存储引擎支持意向锁设计比较简练，其意向锁即为表级别的锁。由于InnoDB存储引擎支持的是行级别的锁，因此意向锁除了全表请求（例如LOCK TABLES ... WRITE）外，不阻止任何其他请求。
若将上锁的对象看做一颗树，那么对最下层的对象上锁，也就是最细粒度的对象上锁，那么分别需要对数据库A，表，页加上意向锁IX，最后对记录r加上X锁。若其中任何一个部分导致等待，那么该操作需要等待粗粒度锁的完成。例如，事务T1试图依次在表1上加IX锁，并在记录r上加X锁，在加锁操作前，已经有另一事务T2已经对表1加了S表锁，此时由于IX和S不兼容，所以T1需要等待T2表锁操作的完成。
表级意向锁与行级锁的兼容性如下矩阵所示。
记录锁是在索引记录上加锁的锁。例如，下面的sql语句会阻止任何其它事务在t.c1=10的所有行记录上进行插入、更新和删除操作。
SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;
记录锁总是锁住索引记录，即使表没有定义索引。因为InnoDB存储引擎会创建隐式的聚集索引，并将其用于记录锁。See Section 14.6.2.1, “Clustered and Secondary Indexes”.
间隙锁是对索引记录之间，或第一个索引记录之前，或最后一个索引记录之后的间隙的锁定。例如，以下sql语句会阻止其他事务将值15插入到t.c1列中，无论该列中是否已有这样的值，因为该范围中所有现有值之间的间隙都被锁定了，即(-∞-10]，(10-20]，(20-∞)这三个间隙范围都被锁定。
SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE
间隙可能跨越单个索引值，多个索引值，甚至为空。间隙锁是性能和并发性之间权衡的一部分，用于某些事务隔离级别中。使用唯一索引锁定行来搜索唯一行的语句，不需要间隙锁定(这不包括搜索条件仅包含多列唯一索引的某些列的情况；在这种情况下，会发生间隙锁定)。例如，如果id列具有唯一索引，则以下语句仅对ID值为100的行使用索引记录锁定，其他会话是否在前面的间隙中插入行也无关紧要。如果id未建立索引或具有非唯一索引，则该语句会锁定前面的间隙。
#【如果id列有唯一索引，则不会发生间隙锁定】 SELECT * FROM child WHERE id = 100;
next-key锁是记录锁和间隙锁的结合，它是谓词锁(predict lock)的一种改进。其设计的目的是为了解决Phantom Problem(幻影问题，幻读)，也就是阻止多个事务将记录插入到同一个范围内而导致的幻读问题。InnoDB存储引擎在默认的事务隔离级别REPEATABLE READ下，使用next-key锁定进行搜索和索引扫描，从而避免了幻像行问题（请参见第14.7.4节“幻像行”）。
InnoDB执行行级锁定的方式是，当它搜索或扫描表索引时会在遇到的索引记录上设置共享或互斥锁(行级锁定)。因此，行级锁实际上是索引记录锁。索引记录上的next-key锁定也会影响该索引记录之前的“间隙”(间隙锁定)。也就是说，next-key锁锁定是索引记录锁定加上索引记录之前的间隙上锁定。
如果一个会话在索引中的记录r上具有共享或排他锁，则另一会话不能按照索引顺序在r之前的间隙中插入新的索引记录。假如，索引包含值10、11、13和20，则next-key锁可以锁定的间隔为(圆括号表示不包括，方括号表示包括)以下范围。对应的还有previous-key锁(包含左侧，不包含右侧)
(-∞, 10] (10, 11] (11, 13] (13, 20] (20, +∞) 对于最后一个间隔，next-key锁定将间隙锁定在索引中的最大值上方，并且“超级”伪记录的值高于索引中的任何实际值。最高不是真正的索引记录，因此，实际上此next-key锁定仅锁定最大索引值之后的间隙。
如果事务T1通过next-key锁锁定了区间(10,11]，(11,13]，当插入新记录12时锁定范围变成了：(10,11]，(11,12]，(12,13]。
临键锁的降级
①当查询的索引含有唯一属性时，InnoDB会对next-key锁进行优化，降级为Record Lock，即仅锁住索引本身，而不是范围。
例如，t表中a为主键且唯一，当会话1执行以下语句：
SELECT * FROM t WHERE a=5 FOR UPDATE;
之后，在会话2执行以下语句会执行成功。
INSERT INTO t SELECT 4；
②next-key锁降级为Record Lock时，仅在查询的列是唯一索引的情况下。如果是辅助索引，则情况完全不同。
例如，t表中a为主键且唯一，b为辅助索引列。在会话1中执行下列sql语句
SELECT * FROM t WHERE b=3 FOR UPDATE;
在新会话2中分别执行以下的sql都会被阻塞。
#阻塞。因为会话1在索引记录a=5上已经加了X锁。 SELECT * FROM t WHERE a=5 LOCK IN SHARE MODE; #阻塞。主键插入4没问题，但插入辅助索引值2在范围(1,3)中，因此阻塞。 INSERT INTO t SELECT 4,2; #阻塞。插入的主键6没有被锁定，插入辅助索引值5也不在(1,3)之间，但其在另一个锁定的范围(3,6)中，因此阻塞。 INSERT INTO t SELECT 6,5;
插入意向锁是间隙锁的一种类型，它是在行插入之前设置的。如果多个事务不是在间隙的同一个位置插入，则无需等待插入到同一索引间隙中的多个事务。
例如，假设有一个记录索引包含键值4和7，两个事务分别插入5和6，那么每个事务都会产生一个加在4-7之间的插入意向锁，获取在插入行上的排它锁，但是不会彼此阻塞，因为行并不冲突。
在InnoDB存储引擎中，对每个含有自增长值的表都有一个自增长计数器(auto-increment counter)。当对含有自增长的计数器的表进行插入操作时，这个计数器会被初始化，执行如下语句来得到计数器的值：
SELECT MAX(auto_inc_col) FROM t FOR UPDATE;
插入操作会根据自增长计数器+1赋值给自增长列。这个实现方式称为AUTO-INC Locking。这种锁其实采用的是一种特殊的表锁机制，由事务在插入进具有AUTO_INCREMENT列的表时获得。
为了提高插入的性能，锁不是在一个事务完成后释放，而是在完成对自增长值插入的SQL语句后立即释放。虽然通过这种方式提升了效率，但仍存在一些性能问题。
①首先，对于有自增长的列的并发插入性能较差，事务必须等待前一个插入的完成(虽然不用等待事务的完成)。
②其次，对于INSERT……SELECT的大数据量的插入会影响插入的性能，因为另一个事务中的插入会被阻塞。
轻量级互斥量的自增长实现机制
从Mysql5.1.22版本中开始，InnoDB存储引擎中提供了一种轻量级互斥量的自增长实现机制，大大提高了自增长值插入的性能。并提供了一个innodb_autoinc_lock_mode 参数，用来控制自增长的模式(默认值为1)，它使您可以选择如何在可预测的自动增量值序列与插入操作的最大并发性之间进行权衡。For more information, see Section 14.6.1.6, “AUTO_INCREMENT Handling in InnoDB”.
注意项
InnoDB中的自增长实现与MyISAM不同，MyISAM存储引擎是表锁设计，自增长不用考虑并发插入的问题。
另外，在InnoDB中，自增长的列必须是索引，且必须是索引的第一个列。如果不是第一个列，则Mysql会抛出异常。而MyISAM存储引擎不存在这样的问题。
InnoDB支持对包含空间列的列进行空间(SPATIAL)索引(参考Section 11.4.8, “Optimizing Spatial Analysis”)
为了处理涉及SPATIAL索引的操作的锁定，next-key锁定不能很好地支持REPEATABLE READ或SERIALIZABLE事务隔离级别。多维数据中没有绝对排序概念，因此尚不清楚哪个是next key。
为了支持具有SPATIAL索引的表的隔离级别，InnoDB使用谓词锁。SPATIAL索引包含最小边界矩形（MBR）值，因此InnoDB通过在用于查询的MBR值上设置谓词锁定来强制对索引进行一致的读取。其他事务不能插入或修改将匹配查询条件的行。
外键用于引用完整性的约束检查。在InnoDB存储引擎中，如果没有显式的对外键列加索引，InnoDB会自动加上一个索引，因为这样可以避免锁表。
对于外键值的插入或更新，因为要进行约束检查，所以首先需要查询父表中的记录，即SELECT父表。SELECT父表时并非使用的一致性非锁定读(MVCC)的方式，因为会发生数据一致性问题，所以使用的SELECT……LOCK IN SHARE MODE这种一致性锁定读方式，即主动对父表加一个S锁。如果此时父表上已经加了X锁，则对父表加S锁的操作必然阻塞。
例如，两个会话依次进行以下操作，两个会话中的事务都没有进行提交或回滚，则会话B会被阻塞。
#会话A(先) BEGIN DELETE FROM parent WHERE id=3; # 在表上加X锁 #会话B(后) BEGIN INSERT INTO child SELECT 2,3; #第2列为外键，插入时会进行约束检查，查询父表，需要对父表加S锁，从而阻塞。
会话A在做删除时会加X锁，会话B在插入时会进行约束检查，需要查询父表，所以要对父表加S锁，从而阻塞。
为什么使用一致性锁定读而非一致性非锁定读？
上面说过，SELECT父表时使用的一致性的锁定读，设想如果使用的一致性非锁定读(MVCC)方式会怎样？会话B会读到父表存在id=3的记录，可以进行插入。但如果会话A将事务提交了，则父表就不存在id=3的记录了。显然父表和子表就会存在不一致的情况。
官方文档：14.7.2.3 Consistent Nonlocking Reads
一致性非锁定读指的是一个读操作发现读取的行正在进行DELETE或UPDATE操作，这时读取操作不会去等待行上锁的释放，相反会去读取行的一个快照版本。这是InnoDB存储引擎默认隔离级别(REPEATABLE READ)下的读取方式。实际上在READ COMMITTED和REPEATABLE READ隔离级别下，InnoDB存储引擎使用的都是非锁定的一致性读。
一个行记录可能有多个快照版本，所以称这种技术为行多版本技术，由此带来的并发控制称之为多版本并发控制(multi-versioned concurrency control，MVCC)。
一致性锁定读，顾名思义就是读取时进行加锁，即显式地对数据库读取操作进行加锁以保证数据一致性。InnoDB存储引擎对于SELECT语句支持两种一致性的锁定读(locking read)操作：
官方文档：14.7.3 Locks Set by Different SQL Statements in InnoDB
SELECT ... FROM
是一致性读，读取数据库的快照且不会设置任何锁，除非事务隔离级别设置成了SERIALIZABLE。
当设置为SERIALIZABLE隔离级别时，搜索会在它遇到的索引记录上设置共享的next-key锁。但对于使用唯一索引搜索唯一行的行来锁定的语句，仅在索引上使用记录锁(next-key锁降级为record lock)。
SELECT ... FOR UPDATE SELECT ... LOCK IN SHARE MODE
在扫描行时获得锁，并有望针对不符号查询条件的结果集的行释放锁(例如，不满足where条件)。但是，在某些情况下行可能不会立即解锁，因为结果行与其原始源之间的关系在查询执行过程中会丢失。例如，在UNION查询中，在评估是否符合结果集之前，表中被扫描(并锁定)行可能被插入到临时表中。在这种情况下，临时表中的行与原始表中的行之间的关系将丢失，并且直到查询执行结束后者才被解锁。
SELECT ... FOR UPDATE：会在搜索时遇到的索引记录上设置排它的next-key锁。但对于使用唯一索引搜索唯一行的行来锁定的语句，仅在索引上使用记录锁。
SELECT ... LOCK IN SHARE MODE：会在搜索时遇到的索引记录上设置共享的next-key锁。但对于使用唯一索引搜索唯一行的行来锁定的语句，仅在索引上使用记录锁。
对搜索遇到的索引记录， SELECT ... FOR UPDATE 会阻止其他会话执行SELECT ... LOCK IN SHARE MODE，或在某种事务隔离级别下的读取操作。一致性的读将忽略读取视图中存在的记录上设置的任何锁定。
UPDATE ... WHERE ...
会在搜索遇到的每条记录上设置排它的next-key锁。但是，对于使用唯一索引搜索唯一行的行来锁定的语句，仅在索引上使用记录锁。
当UPDATE修改聚簇索引记录时，将对受影响的辅助索引记录进行隐式锁定。在插入新的二级索引记录之前执行重复检查扫描时，以及在插入新的二级索引记录时，UPDATE操作还会在受影响的二级索引记录上获得共享锁。
DELETE FROM ... WHERE ...
会在搜索遇到的每条记录上设置排它的next-key锁定。但是，对于使用唯一索引搜索唯一行的行来锁定的语句，仅在索引上使用记录锁。
insert
在插入的行上设置排它锁(X)。该锁是索引记录锁，不是next-key锁（即没有间隙锁），并且不会阻止其它会话插入到插入行之前的间隙中。
在插入行之前，会设置一种称为插入意向间隙锁(Insert Intention Lock)的间隙锁。前面已经介绍过了，如果多个事务不是在间隙的同一个位置插入，则无需等待插入到同一索引间隙中的多个事务。
更多sql语句使用的锁情况，请参考官方文档。
INSERT ... ON DUPLICATE KEY UPDATE REPLACE INSERT INTO T SELECT ... FROM S WHERE ... CREATE TABLE ... SELECT ... LOCK TABLES
官方文档：
死锁的可能性并不会受到事务隔离级别的影响，因为事务隔离级别仅改变读操作的行为，而死锁因写操作才会发生。
锁升级(Lock Escalation)是指当前锁的粒度降低。比如，数据库可以将一个表的1000个行锁升级为1个页锁，或者将页锁升级为表锁。
InnoDB存储引擎不存在锁升级的问题。因为其不是根据每个记录来产生行锁的，相反，其根据每个事务访问的每个页进行管理的，采用的是位图的方式。因此不管一个事务锁住页中一个记录还是多个记录，其开销通常都是一样的。
1.锁分为行级别锁和表级别锁，按照属性来分，行级别锁可分为共享锁(S)和排它锁(X)，它们都属于悲观锁的范畴。
2.为了支持细粒度锁定，InnoDB设计了意向锁，它是表级别锁。
3.行级锁有3种算法：记录锁(Record Lock)、间隙锁(Gap Lock)、临键锁(Next-Key Lock)。
记录锁仅锁住索引本身，间隙锁锁住区间范围，而临键锁既锁住索引本身又锁住区间。
see Section 11.4.8, “Optimizing Spatial Analysis”
标签：矩阵 inno 事务隔离级别 esc 级别 一个 避免 通过 vertica
原文地址：https://www.cnblogs.com/rouqinglangzi/p/10232592.html
