MySQL锁机制与事务隔离级别

01什么是事务？       事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。　　原子性(Atomicity) ：事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。　　一致性(Consistent) ：在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。　　隔离性(Isolation) ：数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。　　持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。02事务的实现原理1、MySQL的日志系统

日志系统主要有Redo Log(重做日志)、Undo Log和binlog(归档日志)。Redo Log是InnoDB存储引擎层的日志，binlog是MySQL Server层记录的日志， 两者都是记录了某些操作的日志(不是所有)，自然有些重复（但两者记录的格式不同）

2、事务实现原理       通过上面我们可以知道，事务的特点为：原子性、持久性、隔离性、一致性，是什么机制才能保证事务的这四个特性呢？

 

事务的原子性是通过undo log来实现的

事务的持久性是通过redo  log来实现的

事务的隔离性是通过（读写锁+MVCC）来实现的

事务的一致性是通过原子性、持久性、隔离性来实现的

 

2.1.1、原子性实现原理---Undo Log       ● Undo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来进行多版本并发控制（简称MVCC）        ● 在操作任何数据之前，首先将数据备份到一个地方(这个存储数据备份的地方称为Undo Log)。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。        ● 注意: Undo Log是逻辑日志，可以理解为:            ▶ 当delete一条记录时，Undo Log中会记录一条对应insert记录            ▶ 当insert一条记录时，Undo  Log中会记录一条对应delete记录            ▶当update一条记录时，Undo Log中会记录一条对应相反的update记录2.1.2、持久性实现原理---Redo Log

 和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只将Redo Log持久化即可，不需要将数据持久化，当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化，系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。

 

2.1.3、隔离性实现原理---锁

 在MySQL的InnoDB存储引擎中，锁可以分为两类:

（1）共享锁: 共享锁定是将对象数据变为只读形式，不能进行更新，所以也成为读取锁定，简称读锁。

（2）排他锁: 排他锁定是当执行插入/修改/删除操作的时候，其它事务不能读取该数据，因此也成为写入锁定，简称写锁。

 

     相对其他数据库而言，MySQL 的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MylSAM、MEMORY存储引擎采用的是表级锁，InnoDB存储引擎既支持行级锁，也支持表级锁，但默认情况下是采用行级锁。

（1）表级锁: 开销小、加锁快、不会出现死锁、锁定粒度大、发生锁冲突的概率最高、并发度最低。

（2）行级锁: 开销大、加锁慢、会出现死锁、锁定粒度最小、发生锁冲突的概率最低、并发度也最高。

         对于表级锁和行级锁并没有优劣之分，需根据实际需求进行选择，比如对并发度要求高可以选择行级锁等。3、Redo Log vs Undo Log

（1） Redo Log重做日志，提供前滚操作; Undo Log是回退日志，提供回滚操作。

（2） Redo Log通常是物理日志，记录的是数据页的物理修改而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页恢复数据页，且只能恢复到最后一次提交的位置)。

（3） Undo Log用来回滚行记录到某个版本。Undo Log一般是逻辑日志，根据每行记录进行记录。

4、浅谈binlog

竟然说到了MySQL的日志，binlog不得不提，它记录了所有的DDL和DML语句（除了数据查询语句select）,以事件形式记录，还包含语句所执行的消耗的时间。

binlog三种模式及其优缺点：

（1） statement: 基于SQL语句的模式，某些语句中含有-些函数，例如UUID NOW等在复制过程可能导致数据不一致甚至出错。

（2）row: 基于行的模式，记录的是行的变化，很安全。但是binlog的磁盘占用会比其他两种模式大很多，在一些大表中清除大量数据时在binlog中会生成很多条语句，可能导致从库延迟变大。

（3） mixed: 混合模式，根据语句来选用是statement还是row模式。

03事务的并发问题

 

        单个事务对数据库的操作是串行的，不会存在并发问题，但是多个事务对数据库的操作就会产生并发问题，分别为：脏读、不可重复读、幻读。1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据。通俗讲就是事务A读取了其它事务未提交的数据（脏数据）。2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改和删除，幻读侧重于新增。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。

 

04事务的隔离级别

 

下面通过举例来说明这4种事务隔离级别：

1、读未提交

    （1）打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值。

    （2）在客户端A的事务提交之前，打开另一个客户端B，更新表account。    （3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据。

    （4）一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据。

    （5）在客户端A执行更新语句update account set balance = balance - 50 where id =1，lilei的balance没有变成350，居然是400，是不是很奇怪，数据不一致啊，如果你这么想就太天真 了，在应用程序中，我们会用400-50=350，并不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别。

 

2、读已提交

    （1）打开一个客户端A，并设置当前事务模式为read committed（未提交读），查询表account的所有记录。    （2）在客户端A的事务提交之前，打开另一个客户端B，更新表account。

    （3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题。

    （4）客户端B的事务提交

    (5) 客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题。

3、可重复读

    （1）打开一个客户端A，并设置当前事务模式为repeatable read，查询account表中id为4的记录。

    （2）在客户端A的事务提交之前，打开另一个客户端B，向account表中插入一条记录，并提交。

    （3）在客户端B提交之后，同样地，客户端A向account表中插入id为4的记录并再次查询id为4的记录，发现主键重复但又读取不到数据，感觉像自己读过一样，这就造成了幻读。