mysql事务的实现原理_mysql事务底层实现原理大解析

四大特性

事务具有ACID四个特性。也即：原子性，一致性，隔离性，持久性。

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

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

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

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

Redo log 重做日志

重做日志用来实现事务的持久性，即D特性。它由两部分组成：

①内存中的重做日志缓冲 ②重做日志文件

一看有内存和磁盘上的两个对应实体，我们就知道这样做一定是为了效率考虑，因为内存的读写效率要比磁盘读写效率高太多。

Innodb是支持事务的存储引擎，在事务提交时，必须先将该事务的所有日志写入到redo日志文件中，待事务的commit操作完成才算整个事务操作完成。在每次将redo log buffer写入redo log file后，都需要调用一次fsync操作，因为重做日志缓冲只是把内容先写入操作系统的缓冲系统中，并没有确保直接写入到磁盘上，所以必须进行一次fsync操作。因此，磁盘的性能在一定程度上也决定了事务提交的性能。

通过innodb_flush_log_at_trx_commit来控制redo log刷新到磁盘的策略。该参数的默认值为1，表示每次提交事务时都执行一次fsync操作。0则表示事务提交时不进行写入重做日志文件，这个写入操作由master thread进程来完成，master thread每一秒会进行一次重做日志文件的fsync操作。2则表示事务提交时将重做日志写入重做日志文件，但仅写入文件系统的缓存中，并不进行fsync操作。用户可以通过设置0或者2啦提高事务提交的性能，也可以设置1来要求确保redo log是写入文件中的，总之三种方法各有利弊。

Undo log

第二部分是Undo log，它可以实现如下两个功能：

1.实现事务回滚

2.实现MVCC

undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。

当执行回滚时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，帮助用户实现一致性非锁定读取

redo log与binlog

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

(1)作用不同：redo log是用于crash recovery的，保证MySQL宕机也不会影响持久性；binlog是用于point-in-time recovery的，保证服务器可以基于时间点恢复数据，此外binlog还用于主从复制。

(2)层次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的服务器层(可以参考文章前面对MySQL逻辑架构的介绍)实现的，同时支持InnoDB和其他存储引擎。

(3)内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。

(4)写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元：

前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略，修改innodb_flush_log_at_trx_commit参数可以改变该策略，但事务的持久性将无法保证。 除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，这样的好处是不一定要等到commit时刷盘，commit速度大大加快。