Mysql技术内幕InnoDB存储引擎读书笔记--《六》锁

本文链接：https://blog.csdn.net/FreeeLinux/article/details/74078097

数据库系统区别于文件系统的一个关键特性，一方面要最大程度地利用数据库的并发访问，另外一方面还要确保每个用户能以一致的方式读取和修改数据。

锁的类型

InnoDB存储引擎实现了如下两种标准的行级锁：

共享锁（S LOCK），允许事务读一行数据
排它锁（X LOCK），允许事务删除或者更新一行数据

当一个事务已经获得了行r的共享锁，那么另外的事务可以立即获得行r的共享锁，因为读取并没有改变行r的数据，我们称这种情况为锁兼容。但如果有事务想获得行r的排它锁，则它必须等待事务释放行r上的共享锁——这种情况我们成为锁不兼容。

InnoDB存储引擎支持多粒度锁定，这种锁定允许在行级上的锁和表级上的锁同时存在。为了支持在不同粒度上进行加锁操作，InnoDB存储引擎支持一种额外的锁方式，我们称之为意向锁。意向锁是表级别的锁，其设计目的主要是为了在一个事务中揭示下一行将被请求的锁的类型。

意向共享锁(IS Lock），事务想要获得一个表中某几行的共享锁。
意向排它锁（IX Lock），事务想要获得一个表中某几行的排它锁。
因为InnoDB支持的是行级别的锁，所以意向锁其实不会阻塞除全表扫以外的任何请求。

一致性的非锁定读操作

一致性的非锁定读操作（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi versioning）的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE、UPDATE操作，这时读取操作不会因此等待行上的锁释放，相反，存储引擎会去读取一个快照数据。

快照数据是指该行之前版本的数据，该实现是通过Undo段来实现。而Undo用来在事务中回滚数据，因而快照数据本身是没有额外的开销。此外，读取快照数据是不必要上锁的，因为没有必要对历史的数据进行修改。

这种并发控制，就是多版本并发控制。

在Read Comitted和Repeatable Read（InnoDB存储引擎的默认事务隔离级别）下，InnoDB存储引擎使用非锁定的一致性读。然后，对于快照数据的定义却不相同。在Read Comitted事务隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据。在Repeatable事务隔离级别下和Repeatable Read事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本。

所以，对于Read Commited的事务隔离级别而言，其实违反了事务的隔离性。

加锁方式

SELECT…FOR UPDATE 对读取的行记录加一个X锁。其他事务想在这些行上加任何锁都会被阻塞。
SELECT…LOCK IN SHARE MODE 对读取的行记录加一个S锁。其他事务可以向锁定的记录加S锁，但是对于家X锁，则会被阻塞。

自增长和锁

Mysql的auto_increment这个自增长计数器是加锁的，使用如下语句来得到计数器的值：
SELECT MAX(auto_inc_col) FROM t FOR UPDATE;
这个锁其实是采用一种特殊的表锁机制，为了提高插入的性能，锁不是再一个事务完成后才释放，而是在完成对自增长值插入的SQL语句后立即释放。

外键和锁

对于外键值得插入或者更新，首先需要查询父表中的记录，即SELECT父表，但是对于父表的SELECT操作，不是使用一致性非锁定读的方式，因为这样会发生数据不一致的问题，因此这时使用的是SELECT … LOCK IN SHARE MODE方式，主动对父表加一个S锁，如果这时父表上已经这样加X锁，那么子表上的操作会被阻塞。