mysql事务和锁

Innodb引擎的锁机制

InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁

事务的ACID

事务是为了实现业务上完整性而实现了，他可以由多条sql语句组成，这些语句要么全部成功，否则发生任何错误都将会回滚。事务具有4个属性。称为事务的ACID属性

• 原子性（Actomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
• 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。并且在操作数据的过程中，无论使用并行或者是串行的方式执行，得到的最后的结果应该是一致的。
• 隔离性（Isolation）：隔离性是描述多个事务之间操作共同资源时如何处置的问题，选择哪一种隔离方式。数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
• 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

并发事务带来的问题

相对于串行处理来说，并发事务处理能大大增加数据库资源的利用率，提高数据库系统的事务吞吐量，从而可以支持可以支持更多的用户。但并发事务处理也会带来一些问题，主要包括以下几种情况。

• 更新丢失（Lost Update）：当两个事务同时更新一个数据时候，由于同时读取数据表中的数据，并且两个事务都以自己读到的数据为基础进行更新，在写入表时候，后写入的值会覆盖先写入的值，原本应该两次更新的操作丢失了一次。“更新丢失”通常应该是完全避免的，但不能单靠数据库控制器解决，而应该时应用层的责任。
• 脏读（Dirty Reads）：一个事务读取到了另一个事务未提交的数据，该数据可能会发生回滚而失效。
• 不可重复读（Non-Repeatable Reads）：一个事务执行时，前后使用相同的查询语句，第二次读取时发现数据被修改，两次读取到的数据不一致。
• 幻读（Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。

不可重复读和幻读都是两次的查询结果不同，但是不可重复读是倾向于行数据被修改，这个更好解决，对该行加锁即可。而幻读强调的是执行相同的查询时增加或者删除了一整行的数据。处理这个问题锁单行是无法解决的，需要通过锁表实现。这也是两个问题分开提出的原因。

事务的隔离级别

上面的问题在所有关系型数据中都是存在，所以在ISO/ANSI SQL92标准中定义了4个事务隔离级别来分别解决以上的问题。

隔离级别	脏读	不可重复读	幻读
读未提交	存在	存在	存在
读已提交	解决	存在	存在
可重复读	解决	解决	存在
序列化	解决	解决	解决

MySQL的隔离级别的具体实现和上面sql标准中定义的有一个区别的地方，可重复读的隔离级别下，MySQL解决了幻读的问题，而MySQL的默认隔离级别为可重复读，该级别可以避免上述的所有问题。

隔离级别的实现

实现事务的隔离级别，一般可以通过两种方式实现

• 使用锁，通过行锁或者表锁来保证共享的数据只能被一个事务获取，其他事务只能等待前一个事务完成后才能进行处理。
• MVCC并发控制：通过一定机制生成一个与请求时间点一致性数据快照（Snapshot），并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度，好像是数据库可以提供同一数据的多个版本，因此，这种技术叫做数据多版本并发控制（ＭultiVersion Concurrency Control，简称MVCC或MCC），也经常称为多版本数据库。

Innodb的锁机制实现

行锁

innodb实现了两种类型的行锁：

• 共享锁(读锁)：一个事务获取了该行数据的共享读锁， 其他事务还可以继续获取该数据的共享读锁，但是无法获取排他的写锁。
• 排他锁(写锁)：任意一个事务获取了该行数据的排他写锁后，该行数据共享锁和排他锁都无法被获取。直到该锁被释放。

一个事务中通过update，insert，delete等语句去修改一行数据，MySQL都会自动尝试的去获取一个排他性的写锁，这个获取锁的操作就会与其他获取同一个锁的事务竞争，只会有一个事务得到锁而执行操作，另一个继续竞争。而直接使用select 语句进行查询是不用获取锁的，可以随时进行查询，但是这也可能会造成获取到其他事务正在修改的数据(如果并不关心这一点可以使用该方式)。也可以在查询数据时使用锁去获取。

select * from table ..... for update：对获取的这些数据添加一个排他的写锁，在事务提交前，其他事务都不能读写这些被加锁的数据。

select * from table ..... lock in share mode：对获取的这些数据添加一个共享读锁，其他事务可以读取，但是不能修改数据。

行锁的实现方式

MySQL行锁是通过给索引上的索引项加锁来实现的，这一点与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。MySQL这种行锁实现特点意味着：只有通过索引条件检索数据，才使用行级锁，否则，InnoDB将使用表锁！ 

例如 select * from table where name=tom，如果name字段没有索引，将会进行全表扫描来获得数据，innodb在扫描之前将会锁住整个表，直到事务提交。如果name字段有索引，MySQL实际会在索引上锁，但是有多个索引时，也会对数据进行上锁，以避免使用不同的索引获取值时出现数据的并发访问问题。

但是并不是使用了索引字段进行查询就能保证查询一定走了索引，某些情况下，使用索引可能没有直接全表扫描的效率高，应该使用explain查看查询计划

意向锁（表锁）

意向锁也分为两种：

• 意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
• 意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

意向锁是InnoDB自动加的，不需用户干预。例如进行全表扫描时，将会自动意向锁加锁。同时获取表锁前，也会确保该表中不存在行锁才能获取，否则任然可能会造成锁冲突。这四种锁的冲突与兼容情况如下：

锁	X	IX	S	IS
X	冲突	冲突	冲突	冲突
IX	冲突	兼容	冲突	兼容
S	冲突	冲突	兼容	兼容
IS	冲突	兼容	兼容	兼容

 

其他事务想要获取的锁的类型，必须和当前事务以获取锁的类型相互兼容，其他事务才能正常的获取，否则将会阻塞等待锁释放。

间隙锁

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁 （Next-Key锁）。

例如我们进行范围查询时候， select * from id > 20此时我们指定的范围是id > 20，表中的这些数据都会被加锁而避免被修改，同时，他们这些数据之间间隙也是会被加锁的，如果插入一个id = 30的数据(表中没有改数据)，人仍然会被阻塞而禁止插入，这也是解决幻读问题一种实现。

所以避免范围查询也是一个数据库优化方式，如果可以，应该尽量的减小这个范围， 最好使用相等的条件查询。

几种使用锁的情况

以上的现象是在MySQL的默认隔离级别repeated read下，使用read commited隔离级别时有不同表现。

read commited 隔离下锁的表现：

• 通过主键或者索引加锁，只会对查询的行加锁，其余未加锁行不受任何影响，其他事务可以自由访问。
• 使用for update和全表扫描的方式加锁，同样只会锁住被查出的行，其余行没有被写锁锁住，可以正常获取。
• 插入数据不会受锁影响，可直接插入数据，也不能避免幻读

repeated read隔离级别下锁表现

• 通过主键或者索引加锁，只会对查询的行加锁，其余未加锁行不受任何影响，其他事务可以自由访问。
• 使用全表扫描的方式加排他锁，表所有的行都会被锁住，即使不是被查询的数据，因为使用了表锁。
• 插入数据受到间隙锁的控制。加锁时候，根据where或者其他条件进行的查询，在这个where条件的范围内部的数据，都不能被修改，并且其他事务想要插入一条数据，必须不在这个范围内部，否则将会触发锁而阻塞。
• 全表扫描的情况下，全部的数据和间隙都会被锁住，也就无法插入数据，从而避免幻读。

同时还需要注意以下问题：

• 当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
• 由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。例如使用查询条件where name=tom and age=18 和 where name=tom and age=20，如果name字段建立了索引，虽然查询行数据时两行数据，但是由于使用的索引字段的条件时相同的，所以任然会锁冲突。

查看锁争抢情况

通过一个MySQL内部状态量来查看争用情况show status like 'innodb_row_lock%';

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_time          | 45336 |
| Innodb_row_lock_time_avg      | 6476  |
| Innodb_row_lock_time_max      | 12442 |
| Innodb_row_lock_waits         | 7     |
+-------------------------------+-------+

如果InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高，说明锁竞争越严重(以上数据是测试了许多锁竞争后情况后的数值)，我们需要分析锁竞争的原因，使用方案优化

MVCC并发控制的实现

仅仅使用上面的锁方案，在实现各个级别隔离性前提下，只能做到多个事务同时并发读取，而多个事务同时读写或多个事务同时写都会触发锁竞争，使得这些事务串行化，从而降低了并发量。而使用mvcc版本，可以实现同时读写时的并发执行。

mvcc想要实现的是读写之间的并发，也就是一个事务在读取内容的时候，可以有其他的一个写操作的事务(仅此一个，否则多个写操作并发)在执行，并且这不会破坏数据的一致性，同时达到隔离级别的要求。

快照读和当前读

数据库的更改会在undo log中形成一个版本链的关系，每次insert 或 update一个数据，都会创建该记录的新的版本 （delete也看作update操作，他会把改变记录的deleted位标记），并在该记录的行信息中修改该记录的事务的唯一id，将来作为事务可见性的判断。基于这个版本链，在MVCC并发控制中，每次写操作会创建一个新的版本，而读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。

快照读：当开启一个事务之后，第一次执行普通的select语句时(不加锁的select语句)，会将本次在版本连中最新的一次已提交的记录做一次快照并暂存，且这个快照只有该事务可见，其他事务可以在原始的版本链中修改数据，但该事务的快照内容不会修改。

当前读：读取的是版本链中记录的最新的已提交的版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。

快照读和当前读分别包括以下语句：

快照读：使用普通的 select 语句(不包括 select ... lock in share mode, select ... for update)都是快照读。

当前读：select ... lock in share mode，select ... for update，insert，update，delete 语句，这些语句获取的是数据库中的最新数据。

InnoDB存储引擎默认事务隔离级别是RR(可重复读)，是通过 "行级锁+MVCC"一起实现的，正常读的时候不加锁，写的时候加锁。而 MCVV 的实现依赖：隐藏字段、Read View、Undo log。

隐藏字段

列名	是否必须	占用空间	描述
row_id	否	6	行唯一标识，递增
transaction_id	是	6	表示最近一次对本记录行作修改（insert | update）的事务ID，delete操作是一个update操作，非真删除，会更改删除位，deleted
roll_pointer	是	7	回滚指针，指向当前记录行的undo log信息

 

Read View

这是一个读视图，也就是一个快照，当开启一个事务之后，使用普通的select第一次读取内容时，就会创建一个readview快照信息，记录当前时间点一些信息。主要包括

• 当前出现过的最大事务id+1，
• 当前活跃的事务列表，逆序排列，trx_ids
• 活跃事务列表中的最小id
• 创建的当前事务的id。

Read view主要配合undo log版本链做数据的可见性分析。

Undo log

undo log使用一个版本链来记录当前版本的数据和历史版本的数据，事务可以进行回滚也是利用undo log来实现的。

undo log主要会记录数据的insert和update操作，至于delete也是update操作，是将标记删除位的假删除。每次操作都会创建创建一个新的版本数据，并在数据的隐藏字段中记录了修改该数据事务id。这样即使该事务操过程中其他的事务对数据进行了修改，该线程比较这个事务id的不同，可以判断出哪个版本的数据是在本事务开启后才进行修改，从而不去读取哪些数据，也就是那些数据对本事务来说是不可见的，然后从版本链中找到由本事务最新修改的内容，在该事务读取数据的时候，不用对数据加锁。

简要的过程为

undo log中记录了一个版本链信息，数据的每一个版本都记录了修改他的事务id，当在一个事务中使用普通的查询语句时，将会生成一个Readview信息，这里有两种情况：

• 在RR，可重复读的模式下，readview的内容是不变，假如事务1第一次读取了数据，创建read view并将活跃事务2记录，然后事务2写入数据将其修改了并提交，事务1从新读取数据，由于视图没有修改，会将事务2修改的数排除在外，读取的还是事务1第一次读取的内容。这就不会出现不可重复读的情况，满足可重复读的隔离条件要求。
• 在RC，读已提交的模式下，每次新的查询都会生成新的read view，事务1第一次查询，生成第一个视图，并将事务2活跃线程记录，在其提交前都无法读取事务2修改的数据，当事务2提交后，事务2已经不是活跃线程，重新建立的视图中的活跃事务列表中没有记录事务2，则事务2的数据对事务1变得可见。这也满足读已提交的隔离条件，并会发生不可重复读问题。