万网续费登录网站男男做的视频网站

1.事务的四大特性

1.1 原子性 Atomicity

一系列的操作，要么全部执行完毕，要么全部失败。这一系列的操作具有原子性。

1.2 一致性 Consistency

一致性是原子性、隔离性、持久性保证后的一个事务状态，代表数据库事务前后的完整性是否有被破坏。

1.3 隔离性 Isolation

多个事务的操作互相之间不要影响彼此的状态转移，事务与事务之间具有隔离性质。

1.4 持久性 Durability

数据状态完成了转移以后结果将会永久保存。

2.redo日志概念和作用

数据的访问和更改都会在Buffer Pool中更新，对于一个已经提交了的事务，在事务提交后即时发生了系统故障，这个事务对于数据库所做的更改仍然不能丢失。因为InnoDB是以页为单位管理数据，如果事务只修改了一小部分数据就没必要都立即刷盘，只需要将修改的内容记录一下。即使发生了系统崩溃，只需要按照这个修改记录日志重新回放一遍就可以恢复事务数据。这个记录修改的记账本叫重做日志Redo_log。
Redo日志有两个好处：

  - 空间占用小，只需要记录表空间ID、页号、记录偏移量、更新的值。- Redo日志是顺序写入磁盘，一个事务可能有多条日志，这些日志都是顺序写入磁盘、顺序IO。

3.redo日志格式

Redo日志提供了几十种日志格式来记录不同场景的修改，其中绝大部分都有通用的日志格式结构段。

  - type：redo日志的格式，MySQL一共提供了53种不同类型的redo日志格式。- data：这一条redo日志的具体记录内容。

简单的redo日志记录：

4.Mini-Transaction

InnoDB的数据修改都发生在Buffer Pool中，所以在修改完页面之后，需要记录相应的redo日志。InnoDB规定了若干个不可分割的组，例如：

  - 更新Max Row ID的redo日志为一组，不可分割。- 更改B+Tree页面的redo日志是一组，不可分割，等等。

MySQL规定对数据页面的一次原子访问的过程叫Mini-Trancaction(MTR)，例如修改一次Max Row ID算是一次原子访问、向B+Tree添加页面也算是一次原子访问。
事务、SQL语句、MTR、redo的关系如下：

5.redo日志的写入过程

redo日志都是放在大小为512字节的redo页中管理。

header中包含了页号信息、checkpoint、redo页数据占用多大等。

5.1 Log_Buffer redo日志缓冲区

和Buffer Pool的想法一样，redo日志不可能频繁和磁盘进行IO交互。MySQL服务在启动的时候就会向操作系统申请一块连续的内存空间，称之为redo log buffer redo日志缓冲区，简称log buffer。这片连续的内存空间由若干个redo页组成。这个log buffer的默认大小是16MB，可调。

5.2 redo日志顺序写入Log Buffer

redo日志写入log buffer中是顺序无缝写入的，先写入redo页中，然后满了以后再写下一个页。而且redo日志不是一条一条写，而是一次性写入一个MTR。

6.redo日志刷盘时机

  - bug buffer空间不足50%时，强制刷盘。- 事务提交时(默认刷盘，也可以配置不立即刷盘，而是刷到操作系统的PageCache中)- 后台线程每秒一次的频率将log buffer的数据刷盘。- 正常关闭MySQL服务时。- 做checkpoint检查点时。

7.LSN（Log Sequence Number）和checkpoint

redo日志的量在不断的递增，InnoDB提出了一个LSN的全局变量来记录当前总共已经写入redo日志量。LSN的初始值是8704。LSN的值就是计算log buffer的占用数据偏移量来计算得到。LSN值越小，说明这条redo日志产生的越早。
redo日志文件数量是可以有多个的，形成一个redo日志文件组，默认是2个，最大100个文件。每个文件默认大小48MB，可调。
redo日志文件组的容量是有限的，redo日志文件也是复用的，会造成追尾覆盖的问题。InnoDB提出了一个checkpoint_lsn的全局变量来标识当前系统中可以被覆盖的redo日志总量是多少，初始值也是8704。例如页A已经从Buffer Pool中刷新到了磁盘，那么它所对应的redo日志就可以被覆盖了，这个过程叫checkpoint。

8.用户线程批量从flush脏页链表中刷出脏页

如果系统修改页面的频率很快，导致lsn增长过快、redo写入也是分频繁。如果后台线程的刷脏页操作不能快速刷出，系统将无法及时执行checkpoint，就需要用户线程从flush链表中将最早的脏页刷盘。然后这些已经刷盘了的脏页对应的redo日志就没用了，就可以执行checkpoint了。

9.崩溃恢复

从redo日志文件组第一个文件的管理信息中找出最近发生checkpoint的信息，然后扫描redo日志文件，一直扫描某个redo页的log_block_hdr_data_len值不为512为止。