MySQL之事务及锁机制

fjian_fresh
355 阅读12分钟

MySQL事务

事务基本要素----ACID

事务是由一组SQL语句组成的逻辑处理单元，具有4个属性，通常简称为事务的ACID属性。

  • A (Atomicity) 原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
  • C (Consistency) 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
  • I (Isolation)隔离性：一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
  • D (Durability) 持久性：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

并发事务处理带来的问题

  • 更新丢失（Lost Update)： 事务A和事务B选择同一行，然后基于最初选定的值更新该行时，由于两个事务都不知道彼此的存在，就会发生丢失更新问题
  • 脏读(Dirty Reads)：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
  • 不可重复读（Non-Repeatable Reads)：事务 A 多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。
  • 幻读（Phantom Reads)：幻读与不可重复读类似。它发生在一个事务A读取了几行数据，接着另一个并发事务B插入了一些数据时。在随后的查询中，事务A就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

幻读和不可重复读的区别：

  • 不可重复读的重点是修改：在同一事务中，同样的条件，第一次读的数据和第二次读的数据不一样。（因为中间有其他事务提交了修改）
  • 幻读的重点在于新增或者删除：在同一事务中，同样的条件,，第一次和第二次读出来的记录数不一样。（因为中间有其他事务提交了插入/删除）

并发事务处理带来的问题的解决办法：

  • “更新丢失”通常是应该完全避免的。但防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。

  • “脏读” 、“不可重复读”和“幻读” ，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决：

事务隔离级别

数据库事务的隔离级别有4种，由低到高分别为

  • READ-UNCOMMITTED(读未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
  • READ-COMMITTED(读已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
  • REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。MySQL的默认事务隔离级别。
  • SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

需要说明的是，事务隔离级别和数据访问的并发性是对立的，事务隔离级别越高并发性就越差。所以要根据具体的应用来确定合适的事务隔离级别，MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 。

这里需要注意的是：与 SQL 标准不同的地方在于InnoDB 存储引擎在 REPEATABLE-READ（可重读) 事务隔离级别下使用的是Next-Key Lock 算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以说InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）已经可以完全保证事务的隔离性要求，即达到了 SQL标准的 SERIALIZABLE(可串行化) 隔离级别，而且保留了比较好的并发性能。

MVCC多版本并发控制

MySQL的大多数事务型存储引擎实现都不是简单的行级锁。基于提升并发性考虑，一般都同时实现了多版本并发控制（MVCC），只是实现机制各不相同。

可以认为 MVCC 是行级锁的一个变种，但它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只是锁定必要的行。

MVCC 的实现是通过保存数据在某个时间点的快照来实现的。也就是说不管需要执行多长时间，每个事物看到的数据都是一致的。

MVCC实现原理

MVCC 的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。所以我们先来看看这个三个 point 的概念

3个隐式字段

表中每行记录除了我们自定义的字段外，还有数据库隐式定义的 DB_TRX_ID, DB_ROLL_PTR, DB_ROW_ID 三个字段

  • DB_TRX_ID： 最近修改(修改/插入)事务 ID：记录创建这条记录/最后一次修改该记录的事务 ID
  • DB_ROLL_PTR： 回滚指针，配合undo日志指向这条记录的上一个版本
  • DB_ROW_ID： 隐含的自增 ID（隐藏主键）

undo日志

undo log 主要分为两种：

  • insert undo log 代表事务在 insert 新记录时产生的 undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃
  • update undo log 事务在进行 update 或 delete 时产生的 undo log ; 不仅在事务回滚时需要，在快照读时也需要

Read View 读视图

什么是 Read View，说白了 Read View 就是事务进行快照读操作的时候生产的读视图 (Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的 ID (当每个事务开启时，都会被分配一个 ID , 这个 ID 是递增的，所以最新的事务，ID 值越大)

什么是当前读和快照读？

当前读：就是读取的是记录的最新版本，读取时还会对读取的记录进行锁定保证其不被其他并发事务修改；

select lock in share mode , select for update; update; insert; delete这些操作都是一种当前读

快照读：不加锁的 select 操作就是快照读，即不加锁的非阻塞读；快照读的实现是基于多版本并发控制，既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

我们可以把 Read View 简单的理解成有三个全局属性

  • list： 用于维护 Read View 生成时刻系统 正活跃的事务 ID 列表
  • up_limit_id： 当前活跃事务ID的最小值
  • low_limit_id： 系统尚未分配的下一个事务 ID
  1. 首先比较DB_TRX_ID < up_limit_id，如果小于，则当前事务能看到DB_TRX_ID所在的记录，如果大于等于进入下一个判断
  2. 接下来判断DB_TRX_ID >= low_limit_id，如果大于等于则代表DB_TRX_ID所在的记录在Read View生成后才出现的，那么对于当前事务肯定不可见，如果小于，则进入下一步判断
  3. 判断DB_TRX_ID是否在活跃事务中，如果在，则代表在Read View生成的时刻，这个事务还是活跃状态，还没有commit，修改的数据，当前事务也是看不到，如果不在，则说明这个事务在Read View生成之前就已经开始commit，那么修改的结果是能够看见的

MVCC 只在 COMMITTED READ（读提交）和REPEATABLE READ（可重复读）两种隔离级别下工作。

RC和RR级别下快照读有什么区别？

RC和RR级别下都是用了MVCC机制，为什么RC只能做到避免脏读问题而不能避免重复读问题，但是RR可以做到？因为生成Read View的时机不同！

  • RC：每次执行快照读的时候生成新的Read View

  • RR：第一次执行快照读的时候生成Read View，并且之后都是这个版本

锁机制

锁是计算机协调多个进程或线程并发访问某一资源的机制。数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。

首先对mysql锁进行划分：

按照锁的粒度划分：行锁、表锁、页锁

按照锁的使用方式划分：共享锁、排它锁（悲观锁的一种实现）

还有两种思想上的锁：悲观锁、乐观锁。

行锁

行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。有可能会出现死锁的情况。  行级锁按照使用方式分为共享锁和排他锁。

共享锁用法：

select ... lock in share mode;

排它锁用法：

select ... for update

表锁

表级锁是mysql锁中粒度最大的一种锁，表示当前的操作对整张表加锁，资源开销比行锁少，不会出现死锁的情况，但是发生锁冲突的概率很大。被大部分的mysql引擎支持，MyISAM和InnoDB都支持表级锁，但是InnoDB默认的是行级锁。

共享锁用法：

LOCK TABLE table_name READ

排它锁用法：

LOCK TABLE table_name WRITE

解锁用法：

unlock tables;

页锁

开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

适用：从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用。

行锁表锁页锁
MyISAM√
BDB√√
InnoDB√√
Memory√

乐观锁与悲观锁

无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。

  • 悲观锁：简单来说就是从数据库层面上进行并发控制，如InnoDB引擎的行锁、表锁等都是悲观锁的体现。
  • 乐观锁：是从应用层面系统层面上去做并发控制，一般默认数据发生并发冲突的情况较少，所以常见的是在数据表中增加版本号字段，每次更新数据时都对版本号进行校验，再进行更新

InnoDB行锁

InnoDB 实现了共享锁和排它锁两种类型的行锁。

同时为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB 还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁：

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

意向锁不会与行级的共享 / 排他锁互斥！！！

  • Record Locks 单个行记录上的锁。对索引项（唯一索引或主键索引）加锁，锁定符合条件的行。其他事务不能修改和删除加锁项；
  • Gap locks 当我们使用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁。对于键值在条件范围内但并不存在的记录，叫做“间隙”。

InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁。

间隙锁基于非唯一索引，它锁定一段范围内的索引记录。间隙锁基于下面将会提到的Next-Key Locking 算法，请务必牢记：使用间隙锁锁住的是一个区间，而不仅仅是这个区间中的每一条数据。

  • Next-key locks

Next-Key 可以理解为一种特殊的间隙锁，也可以理解为一种特殊的算法。通过临建锁可以解决幻读的问题。 每个数据行上的非唯一索引列上都会存在一把临键锁，当某个事务持有该数据行的临键锁时，会锁住一段左开右闭区间的数据。需要强调的一点是，InnoDB 中行级锁是基于索引实现的，临键锁只与非唯一索引列有关，在唯一索引列（包括主键列）上不存在临键锁。

在根据非唯一索引 对记录行进行 UPDATE \ FOR UPDATE \ LOCK IN SHARE MODE 操作时，InnoDB 会获取该记录行的 临键锁 ，并同时获取该记录行下一个区间的间隙锁。

avatar
文章
阅读
粉丝