第七章：事务

最新推荐文章于 2024-10-05 00:24:42 发布

野鸭丁真

最新推荐文章于 2024-10-05 00:24:42 发布

阅读量283

点赞数

文章标签： sql 数据库 java

本文链接：https://blog.csdn.net/codepupil/article/details/123139756

版权

MySQL技术内幕专栏收录该内容

7 篇文章 0 订阅

订阅专栏

认识事物

事务可以由简单SQL语句组成，也可以由一组SqL语句组成。对于事务的操作，要么都成功，要么都不成功。

ACID

A：原子性。要么都成功，要么都不成功。

C：一致性。事务开始和结束，数据库的完整性约束没有被破坏。

I：隔离性。某个事务提交之前对别的事务不可见，锁实现。

D：持久性。事务一旦提交，结果就是永久性的。持久性保证的是高可靠性，而不是高可用性。

分类

扁平事务：所有操作都是同层次的，原子性。

带有保存点的事务：允许事务回滚到之前的某一状态。

链事务：带有保存点的事务当系统崩溃时，所有保存点都会丢失。链事务是指提交一个事务将他隐式传给下一个事务。

嵌套事务：由上层事务控制着各层事务。

事务的实现

redo log保证事务的原子性和持久性。undo log保证事务的一致性。

redo是物理日志，记录对页的修改操作保证事务的持久性。undo是逻辑日志，记录更改前，帮助事务回滚和实现MVCC。

redo

重做日志缓存，重做日志文件。

为了确保每次日志都写入重做日志文件，在每次将重做日志缓冲写入重做日志文件后，InnoDB存储引擎都需要调用一次 fsync操作。由于重做日志文件打开并没有使用O_DIRECT选项，因此重做日志缓冲先写入文件系统缓存。为了确保重做日志写入磁盘，必须进行一次 fsync操作。由于fsync的效率取决于磁盘的性能，因此磁糕的性能决定了事务提交的性能，也就是数据库的性能。

redo log和binlog的区别

重做日志是在InnoDB存储引擎层产生，而二进制日志是在MySQL数据库的上层产生的，并且二进制日志不仅仅针对于InnoDB存储引擎，MySQL数据库中的任何存储引擎对于数据库的更改都会产生二进制日志。
MySQL数据库上层的二进制日志是一种逻辑日志，其记录的是对应的SQL语句。而InnoDB存储引擎层面的重做日志是物理格式日志，其记录的是对于每个页的修改。
此外，两种日志记录写入磁盘的时间点不同。二进制日志只在事务提交完成后进行一次写入。而InnoDB存储引擎的重做日志在事务进行中不断地被写入,这表现为日志并不是随事务提交的顺序进行写入的。

log block

每块大小512字节。log buffer由log block组成。递增循环使用。

log group重做日志组：

由多个重做文件构成。在InnoDB存储引擎运行过程中，log buffer根据一定的规则将内存中的 log block刷新到磁盘。这个规则具体是:
事务提交时；当log buffer中有一半的内存空间已经被使用时；log checkpoint时。

LSN：记录redo log的数量。

LSN不仅记录在重做日志中，还存在于每个页中。在每个页的头部，有一个值FILPAGE_LSN，记录了该页的LSN。在页中，LSN表示该页最后刷新时LSN的大小。因为重做日志记录的是每个页的日志，因此页中的LSN用来判断页是否需要进行恢复操作。

undo

undo存放在数据库内部一个特殊段中。undo位于共享表空间。

一个事务的回滚不能影响别的事务。

undo用于MVCC：当用户读取某一行记录时，该记录被别的事务占用，可以通过undo来读取之前的行版本记录，以此实现非锁定读。

事务提交后不能立马删除undo log和其所在的页。因为可能还有别的事务需要undo log获得行记录之前的版本。事务提交时要将undo log放入一个链表中，是否删除由purge线程决定。

insert undo log可以在事务提交后直接删除，不需要purge。

update undo log包括delete，update操作，要将undo log放入一个链表中，是否删除由purge线程决定。

purge

purge用于最终完成delete和 update操作。这样设计是因为InnoDB存储引擎支持MVCC，所以记录不能在事务提交时立即进行处理。这时其他事物可能正在引用这行，故InnoDB存储引擎需要保存记录之前的版本。而是否可以删除该条记录通过purge来进行判断。若该行记录已不被任何其他事务引用，那么就可以进行真正的delete操作。
在前一个小节中已经介绍过，为了节省存储空间，InnoDB存储引擎的undo log 设计是这样的:一个页上允许多个事务的undo log存在。虽然这不代表事务在全局过程中提交的顺序，但是后面的事务产生的undo log总在最后。此外，InnoDB存储引擎还有一个history列表，它根据事务提交的顺序，将undo log进行链接:InnoDB存储引擎的设计中，先提交的事务总在history列表尾端。undo page存放了undo log，由于可以重用，因此一个undo page中可能存放了多个不同事务的undo log。

InnoDB存储引擎这种先从 history list中找undo log，然后再从undo page中找undolog 的设计模式是为了避免大量的随机读取操作，从而提高purge的效率。