mysql-事务总结

目录

• 事务基本概念
  • 事务的定义
  • 使用事务
  • 自动提交
  • 特殊操作
• ACID特性及其原理
  • 原子性(A)
  • 持久性 (D)
  • 隔离性
    • 脏读、不可重复读和幻读
    • 事务隔离级别
  • 一致性
• mysql事务日志
  • redo log 定义
  • redo log 作用
  • undo log 定义
  • undo log 作用
  • redo log 与 binlog 区别
• mysql锁技术以及MVCC基础
  • 锁机制
    • 锁的分类
  • MVCC
• 总结

事务基本概念

事务的定义

事务（Transaction）是访问和更新数据库的程序执行单元；事务中可能包含一个或多个 sql 语句，这些语句要么都执行，要么都不执行。

使用事务

典型的 MySQL 事务是如下操作的：

start transaction;
……  #一条或多条sql语句
commit;

其中 start transaction 标识事务开始，commit 提交事务，将执行结果写入到数据库。

如果 sql 语句执行出现问题，会调用 rollback，回滚所有已经执行成功的 sql 语句。当然，也可以在事务中直接使用 rollback 语句进行回滚。

自动提交

MySQL 中默认采用的是自动提交（autocommit）模式

在自动提交模式下，如果没有 start transaction 显式地开始一个事务，那么每个 sql 语句都会被当做一个事务执行提交操作。

通过set autocommit=0;，可以关闭 autocommit；需要注意的是，autocommit 参数是针对连接的，在一个连接中修改了参数，不会对其他连接产生影响。

如果关闭了 autocommit，则所有的 sql 语句都在一个事务中，直到执行了 commit 或 rollback，该事务结束，同时开始了另外一个事务。

特殊操作

在 MySQL 中，存在一些特殊的命令，如果在事务中执行了这些命令，会马上强制执行 commit 提交事务；如 DDL 语句(create table/drop table/alter/table)、lock tables 语句等等。

不过，常用的 select、insert、update 和 delete 命令，都不会强制提交事务。

ACID特性及其原理

ACID 是衡量事务的四个特性：

原子性(Atomicity):事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做

一致性(Consistency):事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

隔离性(Isolation):一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

持续性(Durability):也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

原子性(A)

原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做。

如果事务中一个 sql 语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。

实现原理：undo log

实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的 sql 语句。

InnoDB 实现回滚，靠的是 undo log：

当事务对数据库进行修改时，InnoDB 会生成对应的 undo log。

如果事务执行失败或调用了 rollback，导致事务需要回滚，便可以利用 undo log 中的信息将数据回滚到修改之前的样子。

undo log 属于逻辑日志，它记录的是 sql 执行相关的信息。当发生回滚时，InnoDB 会根据 undo log 的内容做与之前相反的工作：

• 对于每个 insert，回滚时会执行 delete。
• 对于每个 delete，回滚时会执行 insert。
• 对于每个 update，回滚时会执行一个相反的 update，把数据改回去。

以 update 操作为例：当事务执行 update 时，其生成的 undo log 中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到 update 之前的状态.

回滚日志除了能够在发生错误或者用户执行 ROLLBACK 时提供回滚相关的信息，它还能够在整个系统发生崩溃、数据库进程直接被杀死后，当用户再次启动数据库进程时，还能够立刻通过查询回滚日志将之前未完成的事务进行回滚，这也就需要回滚日志必须先于数据持久化到磁盘上，是我们需要先写日志后写数据库的主要原因。

持久性 (D)

持久性是指事务一旦提交，它对数据库的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

实现原理：redo log

InnoDB 作为 MySQL 的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘 IO，效率会很低。

为此，InnoDB 提供了缓存(Buffer Pool)，Buffer Pool 中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：

• 当从数据库读取数据时，会首先从 Buffer Pool 中读取，如果 Buffer Pool 中没有，则从磁盘读取后放入 Buffer Pool。
• 当向数据库写入数据时，会首先写入 Buffer Pool，Buffer Pool 中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

Buffer Pool 的使用大大提高了读写数据的效率，但是也带来了新的问题：如果 MySQL 宕机，而此时 Buffer Pool 中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

于是，redo log 被引入来解决这个问题：当数据修改时，除了修改 Buffer Pool 中的数据，还会在 redo log 记录这次操作；当事务提交时，会调用 fsync 接口对 redo log 进行刷盘。

如果 MySQL 宕机，重启时可以读取 redo log 中的数据，对数据库进行恢复。

redo log 采用的是 WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到 Buffer Pool，保证了数据不会因 MySQL 宕机而丢失，从而满足了持久性要求。

当我们在一个事务中尝试对数据进行修改时，它会先将数据从磁盘读入内存，并更新内存中缓存的数据，然后生成一条重做日志并写入重做日志缓存，当事务真正提交时，MySQL 会将重做日志缓存中的内容刷新到重做日志文件，再将内存中的数据更新到磁盘上.

既然 redo log 也需要在事务提交时将日志写入磁盘，为什么它比直接将 Buffer Pool 中修改的数据写入磁盘(即刷脏)要快呢？

主要有以下两方面的原因：

• 刷脏是随机 IO，因为每次修改的数据位置随机，但写 redo log 是追加操作，属于顺序 IO。
• 刷脏是以数据页（Page）为单位的，MySQL 默认页大小是 16KB，一个 Page 上一个小修改都要整页写入；而 redo log 中只包含真正需要写入的部分，无效 IO 大大减少。

隔离性

隔离性是指，多个用户的并发事务访问同一个数据库时，一个用户的事务不应该被其他用户的事务干扰，多个并发事务之间要相互隔离,不能互相干扰.

与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。

严格的隔离性，对应了事务隔离级别中的Serializable(可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。

隔离性追求的是并发情形下事务之间互不干扰。简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)。

那么隔离性的探讨，主要可以分为两个方面：

• (一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性。
• (一个事务)写操作对(另一个事务)读操作的影响：MVCC 保证隔离性。

脏读、不可重复读和幻读

并发情况下，读操作可能存在的三类问题。

①脏读：当前事务(A)中可以读到其他事务(B)未提交的数据（脏数据），这种现象是脏读。

比如A、B两个事务，都操作同一张表，A刚刚对数据进行了操作（插入、修改等）但还没有提交，这时B读取到了A刚刚操作的数据，因为A有可能回滚，所以这部分数据有可能只是临时的、无效的，即脏数据。

②不可重复读：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。

比如A、B两个事务，A中先后有两次查询相同数据的操作，第一次查询完之后，B对相关数据进行了修改，造成A事务第二次查询出的数据与第一次不一致。

脏读与不可重复读的区别在于：前者读到的是其他事务未提交的数据，后者读到的是其他事务已提交的数据。

③幻读：在事务 A 中按照某个条件先后两次查询数据库，两次查询结果的条数不同，这种现象称为幻读。

比如A、B两个事务，事务A操作表中符合条件的若干行。事务B插入符合A操作条件的数据行，然后再提交。后来发现事务A并没有如愿对“所有”符合条件的数据行做了修改

不可重复读与幻读的区别可以通俗的理解为：前者是数据变了，后者是数据的行数变了.

事务隔离级别

sql 标准中定义了四种隔离级别，并规定了每种隔离级别下上述几个问题是否存在。

一般来说，隔离级别越低，系统开销越低，可支持的并发越高，但隔离性也越差。

不同事务的隔离级别，实际上是一致性与并发性的一个权衡与折衷。

在实际应用中，读未提交在并发时会导致很多问题，而性能相对于其他隔离级别提高却很有限，因此使用较少。

可串行化强制事务串行，并发效率很低，只有当对数据一致性要求极高且可以接受没有并发时使用，因此使用也较少。

InnoDB 默认的隔离级别是可重复读,需要注意的是，在 SQL 标准中，RR 是无法避免幻读问题的，但是 InnoDB 实现的 RR 避免了幻读问题。

一致性

一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。

数据库的完整性约束包括但不限于：

• 实体完整性（如行的主键存在且唯一）
• 列完整性（如字段的类型、大小、长度要符合要求）
• 外键约束
• 用户自定义完整性（如转账前后，两个账户余额的和应该不变）

可以说，一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性。此外，除了数据库层面的保障，一致性的实现也需要应用层面进行保障。

mysql事务日志

MySQL 的日志有很多种，如二进制日志、错误日志、查询日志、慢查询日志等。

此外 InnoDB 存储引擎还提供了两种事务日志：

• redo log(重做日志) 用于保证事务持久性
• undo log(回滚日志) 事务原子性和隔离性实现的基础。

redo log 定义

redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中。

假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi）

start transaction;
select balance from bank where name="zhangsan";
// 生成 重做日志 balance=600
update bank set balance = balance - 400;
// 生成 重做日志 amount=400
update finance set amount = amount + 400;
commit;

redo log 作用

mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Boffer Pool(缓冲池)里头，把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。

那么问题来了，如果还没来的同步的时候宕机或断电了怎么办？还没来得及执行上面图中红色的操作。这样会导致丢部分已提交事务的修改信息！

所以引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，系统重启之后在读取redo log恢复最新数据。

所以redo log是用来恢复数据的 用于保障，已提交事务的持久化特性

undo log 定义

undo log 叫做回滚日志，用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息。undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。

每次写入数据或者修改数据之前都会把修改前的信息记录到 undo log。

undo log 作用

undo log 记录事务修改之前版本的数据信息，因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。

所以undo log是用来回滚数据的用于保障 未提交事务的原子性.

1.每条数据变更(insert/update/delete)操作都伴随一条undo log的生成,并且回滚日志必须先于数据持久化到磁盘上

2.所谓的回滚就是根据回滚日志做逆向操作，比如delete的逆向操作为insert，insert的逆向操作为delete，update的逆向为update等。

redo log 与 binlog 区别

我们知道，在 MySQL 中还存在binlog(二进制日志)也可以记录写操作并用于数据的恢复，但二者是有着根本的不同的。

作用不同：

redo log 是用于 crash recovery(故障修复) 的，保证 MySQL 宕机也不会影响持久性；

binlog 是用于 point-in-time recovery (时间点恢复) 的，保证服务器可以基于时间点恢复数据，此外 binlog 还用于主从复制。

层次不同：

redo log 是 InnoDB 存储引擎实现的，

binlog 是 MySQL 的服务器层实现的，同时支持 InnoDB 和其他存储引擎。

内容不同：

redo log 是物理日志，内容基于磁盘的 Page,其记录的是对于每个页的修改

binlog 是逻辑日志，内容是一条条 sql。

写入时机不同：

redo log 的写入时机相对多元。前面曾提到，当事务提交时会调用 fsync 对 redo log 进行刷盘；这是默认情况下的策略，修改 innodb_flush_log_at_trx_commit 参数可以改变该策略，但事务的持久性将无法保证。

除了事务提交时，还有其他刷盘时机：如 master thread 每秒刷盘一次 redo log 等，这样的好处是不一定要等到 commit 时刷盘，commit 速度大大加快。

binlog 在事务提交时写入。

mysql锁技术以及MVCC基础

锁机制

当有多个请求来读取表中的数据时可以不采取任何操作，但是多个请求里有读请求，又有修改请求时必须有一种措施来进行并发控制。不然很有可能会造成不一致。

首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB 通过锁机制来保证这一点。

锁机制的基本原理可以概括为：

• 事务在修改数据之前，需要先获得相应的锁。
• 获得锁之后，事务便可以修改数据。
• 该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁与表锁：按照粒度，锁可以分为表锁、行锁以及其他位于二者之间的锁。

表锁在操作数据时会锁定整张表，并发性能较差；行锁则只锁定需要操作的数据，并发性能好。

但是由于加锁本身需要消耗资源(获得锁、检查锁、释放锁等都需要消耗资源)，因此在锁定数据较多情况下使用表锁可以节省大量资源。

MySQL 中不同的存储引擎支持的锁是不一样的，例如 MyIsam 只支持表锁，而 InnoDB 同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。

锁的分类

读写锁

解决上述问题很简单，只需用两种锁的组合来对读写请求进行控制即可，这两种锁被称为：

共享锁(shared lock),又叫做"读锁"

读锁是可以共享的，或者说多个读请求可以共享一把锁读数据，不会造成阻塞。

排他锁(exclusive lock),又叫做"写锁"

写锁会排斥其他所有获取锁的请求，一直阻塞，直到写入完成释放锁。

通过读写锁，可以做到读读可以并行，但是不能做到写读，写写并行

MVCC

可重复读 解决脏读、不可重复读、幻读等问题，使用的是 MVCC：MVCC 全称 Multi-Version Concurrency Control，即多版本的并发控制协议。

MVCC 的特点：在同一时刻，不同的事务读取到的数据可能是不同的(即多版本)

MVCC 最大的优点是读不加锁，因此读写不冲突，并发性能好。InnoDB 实现 MVCC，多个版本的数据可以共存，主要是依靠数据的隐藏列(也可以称之为标记位)和 undo log。

其中数据的隐藏列包括了该行数据的版本号、删除时间、指向 undo log 的指针等等。

InnoDB的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列， 一个保存了行的创建时间，一个保存了行的过期时间， 当然存储的并不是实际的时间值，而是系统版本号。

当读取数据时，MySQL 可以通过隐藏列判断是否需要回滚并找到回滚需要的 undo log，从而实现 MVCC；隐藏列的详细格式不再展开。

他的主要实现思想是通过数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行。

MVCC在mysql中的实现依赖的是undo log与read view

undo log :undo log 中记录某行数据的多个版本的数据。

read view :用来判断当前版本数据的可见性

总结

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

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

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

而事务的终极大 boss 一致性是通过原子性，持久性，隔离性来实现的.

原子性：语句要么全执行，要么全不执行，是事务最核心的特性。事务本身就是以原子性来定义的；实现主要基于 undo log。

持久性：保证事务提交后不会因为宕机等原因导致数据丢失；实现主要基于 redo log。

隔离性：保证事务执行尽可能不受其他事务影响；InnoDB 默认的隔离级别是 RR，RR 的实现主要基于锁机制、数据的隐藏列、undo log 和类 next-key lock 机制。

一致性：事务追求的最终目标，一致性的实现既需要数据库层面的保障，也需要应用层面的保障。