MySQL事务

用户9381691255360
100 阅读9分钟

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或者撤销操作请求，即这些操作要么同时成功，要么同时失败。

一、事务的特性：ACID

  • 原子性（Atomicity）:事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
  • 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态。
  • 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
  • 持久性（Durability）：事务一旦提交或者回滚，它对数据库中的数据的改变就是永久的。

比如：A某向B某转账1000元。

  • A某的账户上减少1000元，同时B某得账户必须要多1000元。他们的账户要么都变化，要么都不变。这就是原子性的体现。
  • 在转账过程中，数据要一致。A扣除1000元，B必须增加1000元，不能500元，也不能是1200元。这就是一致性的体现。
  • 在转账过程中，A某、B某不能受其他事务的干扰。这就是隔离性的体现。
  • 事务提交后，数据就要持久化磁盘中。这就是持久性的体现。

二、并发事务带来的问题

  1. 脏读：一个事务读到另外一个事务还没有提交的数据。
  2. 不可重复读：一个事务先后读取同一条记录，但两次读取的数据不同。
  3. 幻读：一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了“幻影”。

怎么解决并发事务的问题呢？解决方案是对事务进行隔离。

三、事务的隔离级别

隔离级别脏读不可重复读幻读
read uncommitted 未提交读/读未提交✘✘✘
read committed 读已提交√✘✘
repeatable read(默认)可重复读√√✘
serializable 串行化√√√

注意：事务的隔离级别越高，数据越安全，但是性能越低。

四、undo log和redo log的区别

  • 缓冲池（buffer pool）:主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据（若缓冲池没有数据，则从磁盘加载并缓存），以一定频率刷新到磁盘，从而减少磁盘IO，加快处理速度。
  • 数据页（page）：是InnoDB存储引擎磁盘管理的最小单元，每个页的大小默认为16KB。页中存储的是行数据。

1691222269060(1).jpg

4.1 重做日志redo log

重做日志记录的是事务提交时数据页的物理修改，是用来实现事务的持久性的。该日志文件由两部分组成：重做日志缓冲（redolog buffer），重做日志文件（redolog file），前者是在内存中，后者是在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中，用户在刷新脏页到磁盘发生错误时，进行数据恢复使用。

afd626443565b98af49dd4799422400.png

  1. 不使用redo log日志，在buffer pool中数据页发生变化时，直接将数据同步到磁盘中可以吗？这样做是可以的，但是有严重的性能问题。如果有多个并发事务同时提交，此时同步刷新数据到磁盘，都是随机的磁盘IO，性能非常低。
  2. 使用redo log进行数据同步时，因为日志文件都是顺序追加的，所以是顺序的磁盘IO，性能提升了很多。
  3. 当脏页数据可以正常同步到磁盘文件时，redo log文件作用就不大了。所以每隔一段时间，会对redo log文件进行数据清理。
  4. redo log在磁盘文件中有两份，它们是循环写的。
  5. 这种机制叫做WAL(write-ahead logging)，先写日志。

4.2 回滚日志undo log

回滚日志，用于记录数据被修改前的信息，作用包含两个：提供回滚和MVCC（多版本并发控制）。redo log记录物理日志，而undo log记录逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然。当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。undo log可以实现事务的一致性和原子性。

4.3 undo log和redo log的区别

  1. redo log记录的是数据页的物理变化，服务宕机可用来同步数据。
  2. undo log记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据。
  3. redo log保证了事务的持久性，undo log保证了事务的原子性和一致性。

MySQL中有两种方式保证事务的隔离性：1. 锁：排他锁（如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁）。2. MVCC：多版本并发控制

五、MVCC实现原理

全称Multi-Version Concurrency Controll,多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突。MVCC的具体实现，主要依赖于数据库记录中的隐式字段、undo log日志、read view。

5.1 隐式字段

假设有一个表tb_user，表中的数据如下所示.

idagenameDB_TRX_IDDB_ROLL_PTR
11tom事务2事务1
33cat事务5事务4

如上图，table中含有三列，主键id,age,name，其实记录中还有三个隐式字段。

隐式字段含义
DB_TRX_ID最近修改事务ID，记录插入这条记录或者最后一次修改该记录的事务ID。事务ID默认从1开始，当有新事务时，事务ID会自动加1。
DB_ROLL_PTR回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本。
DB_ROW_ID隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。

5.2 undo log

当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。而update、delete的时候，产生的undo log日志不仅在回滚时需要，mvcc版本访问也需要，不会立即被删除。

5.2.1 undo log版本链

不同事务或相同事务对同一条记录进行修改，会导致该记录的undo log生成一条记录版本链表。链表的头部是最新的旧记录，链表尾部是最早的旧记录。

事务2事务3事务4事务5
开始事务开始事务开始事务开始事务
修改id为30的记录，age改为3查询id为30的记录
提交事务
修改id为30的记录，name改为A3
查询id为30的记录
提交事务
修改id为30的记录，age改为10
查询id为30的记录
查询id为30的记录
提交事务

根据上面表格中列出的事务提交顺序，undo log中的版本链如下图所示。 1691244229284.jpg

5.3 read view

Read View（读视图）是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的（未提交的）事务id。

5.3.1 快照读与当前读
  • 当前读

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：SELECT ... LOCK IN SHARE MODE(共享锁)，SELECT ... FOR UPDATE、INSERT、UPDATE、DELETE（排他锁）都是一种当前读。

  • 快照读
    • read committed：每次select，都生成一个快照读。
    • repeatable read：开启事务后第一个select语句才是快照读的地方。
    简单的select（不加锁）就是快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
5.3.2 read view中包含了4个核心字段
字段含义
m_ids当前活跃的事务id集合
min_trx_id最小活跃事务id
max_trx_id预分配事务id，当前最大事务id+1（因为事务id是自增的）
creator_trx_idread view创建者的事务id

以5.2.1中举例的事务为例，如果此时事务5执行第一个select语句，那么read view中的数据时这样的。

字段值
m_ids3,4,5（不包含事务2，是因为在执行select语句之前，事务2已经提交了）
min_trx_id3
max_trx_id6
creator_trx_id5

5.3.3 版本链数据访问规则

满足下面的一条规则就可以。 trx_id：代表当前事务id。

  1. trx_id == creator_trx_id? 可以访问该版本。该表达式成立，说明数据是当前这个事务更改的。
  2. trx_id < min_trx_id? 可以访问该版本。该表达式成立，说明数据已经提交了。
  3. trx_id > max_trx_id? 不可以访问该版本。该表达式成立，说明该事务是在read view生成之后才开启的。
  4. min_trx_id <= trx_id <= max_trx_id? 如果trx_id不在m_ids中是可以访问该版本的。该表达式成立，说明数据已经提交了。

5.3.4 read view生成时机

不同的隔离级别，生成read view的时机不同。

  • read committed:在事务中每一次执行快照读时生成read view。
  • repeatable read: 仅在事务中第一次执行快照读时生成read view，后续复用该read view。

以5.2.1中的事务5为例。

  1. 在RC隔离级别下，事务5第一次查询时生成一个read view。
read view1
m_ids= [3,4,5]
min_trx_id= 3
max_trx_id= 6
creator_trx_id= 5

事务5第二次查询时又生成一个新的read view。

read view2
m_ids= [4,5]
min_trx_id= 4
max_trx_id= 6
creator_trx_id= 5
  1. 在RR隔离级别下，事务5第一次查询时生成一个read view。
read view3
m_ids= [3,4,5]
min_trx_id= 3
max_trx_id= 6
creator_trx_id= 5

事务5第二次查询时复用第一次查询时生成的read view3。

5.4 查询数据使用的事务

结合undo log版本链和read view，遵循版本链数据访问规则，就可以知道当前查询使用的是哪个事务版本的数据。 比如：在RC隔离级别下生成的read view1，带入版本链数据访问规则，发现当trx_id =4,3时，都不满足。当trx_id =2时，满足第二条。所以事务5的第一次查询到的是事务2提交的后的数据。

avatar
文章
阅读
粉丝