mysql三大日志，结合事务

# mysql事务相关详解
mysql如何保证数据不丢失：https://cloud.tencent.com/developer/article/2384092?from_column=20421&from=20421
如何保证数据一致性：https://cloud.tencent.com/developer/article/2384265
## 先来认识三大日志 undo log, redo log, bin log

背景：一个事务的完整流程
- 开启更改数据库金额0到+100操作
- undo log 创建100记录回滚指针指向0记录，进入buffer pool
- buffer pool进入redo log buffer记录某行+100
- redo log每隔1秒刷盘，快
- buffer pool 带着数据和undo log 定时刷盘，慢
- commit成功，继续刷入undo log
- commit失败，回滚用undo log
- 若commit之后buffer pool未刷盘，系统崩溃，恢复时用已刷盘的redo log

### 一. undo log，用于记录版本，回滚，mvcc
1. ACID之原子性A，undo log在事务开始前把数据存进日志
2. 实现细节：
a. insert记录主键值，回滚时删除
b. update记录旧内容，回滚时还原
c. delete记录旧内容，回滚时还原
3. 版本控制：每条记录都有roll_pointer指向上一个版本的undo log id。
4. mvcc的read view实现方式：
- 假设有6个事务，id1已提交，id3已提交，id5开始但未提交，id6开始但未提交，id7未开始, id9未开始。
- 如果我现在要读这个数据库，那么当前的数据很明显是id3已提交的数据。
- 我们称id3这样的为min_trx_id, id7为max_trx_id, 称当前活跃的读事务min_trx_id < id < max_trx_id 为m_ids。
- 聪明的你已经猜到了什么是read view，就是读取当前事务时间点下的已提交数据，也就是m_ids这样的活跃事务
5. read view有什么用？
- 解决脏读，读的时候不能读到未提交的数据。若不截取快照，实时更新m_ids，即可获得最新数据，但会造成不可重复读。
- 解决可重复读，读的时候，截快照，读的是当前事务时间点下的已提交数据，所以读的时候不能读到未提交的数据。

5. 刷盘时机
- buffer pool 中有 undo 页
- 对 undo 页的修改也都会记录到 redo log。redo log 会每秒刷盘，提交事务时也会刷盘，数据页和 undo 页都是靠这个机制保证持久化的。
- buffer pool详解文章，缓存用到free，flush链表记录，LRU刷盘：https://cloud.tencent.com/developer/article/1828772
- 脏数据会先刷到磁盘日志里，再刷到数据库中，确保持久化


### 二. redo log，用于崩溃恢复
- ACID之持久性D，undo log在事务开始前把数据存进日志
背景：一个事务commit之前执行失败，可以通过undo log回滚到之前的状态。
如果commit之后系统崩溃，最新的数据未刷盘的情况下就丢失了。
为了解决buffer pool刷盘频率慢的问题，mysql引入了实时持久化commit之后的事务，称为redo log。
- 刷盘顺序
- bufferpool语句进来，直接进redolog buffer ，commit之后再进行刷盘持久化
- 采用循环写，满了就从头覆盖旧数据
innodb_flush_log_at_trx_commit参数控制刷盘时机，快or很快
> 参数0：bufferpool 到redolog pool，每隔一秒读取redolog pool刷到磁盘
> 参数1：commit之后直接刷到磁盘
> 参数2：安全和性能的折中方案。commit之后写入内核态page cache，每隔一秒pagecache刷到磁盘


### 三. bin log，用于恢复
背景：数据库硬盘失效了怎么办，数据还有吗？当然是有的，binlog提供了全量数据的恢复方案。
不同于redo，undo在引擎层，binlog是在server层，通过追加写，只保存所有已commit的事务内容。

- 总结：bin log恢复已经刷盘的数据库内容，redolog恢复commit之后且未刷盘的内容，undo log恢复需要回滚commit之前的内容