Mysql基础架构+日志系统

涉及内容：基础架构，两种日志redo log 、 binlog，两阶段提交，刷脏策略，日志的持久化策略，undo log日志。

Mysql基础架构

Mysql可以分为server层和存储引擎层

server层：
    连接器：校验用户名密码、获取权限
    分析器：词法分析、语法分析
    优化器：执行计划生成，选择索引
    执行器：操作引擎，返回数据
存储引擎层：
    存储数据，提供读写接口
    
词法分析：识别出字符串分别是什么、代表什么
语法分析：判断sql是否符号Mysql语法
优化器：存在多个索引，选择索引。使用表连接，选择各个表连接顺序。

Mysql日志系统

Mysql设计的日志，有redo log (回滚日志) 和 binlog(归档日志)

redo log innodb的日志模块 先写日志后写磁盘。一条更新语句，mysql会将此记录在redo log中，并更新内存。之后mysql会在适当时机进行刷脏

binlog server层的日志模块。只能用来归档。没有crash-safe功能

两者区别：
1. redo log 是存储引擎层的，binlog则是server层
2. redo log是循环写的，固定大小。binlog则是追加写，写完写下一个文件
3. redo log是物理文件，记录了在数据页上的直接操作。binlog记录的是逻辑文件，比如在id=2这行的c字段+1

刷脏策略

内存数据页和磁盘数据页不一致，就称为脏页
什么时候会刷脏?
1. redo log日志满了，就必须得进行刷脏
2. 内存满了，加入新的内存页的时候，淘汰旧页
    如果旧页不是脏页，直接淘汰。
    是的话就刷脏
3. Mysql 空闲时间刷脏
4. Mysql关闭时 刷脏

为什么不可以将数据页从磁盘取出，然后应用redo log？
从性能考虑，如果刷脏页，保证每种数据页有两种状态，一种是内存里存在，内存就是正确的，直接返回。另外一种是内存中不存在，就直接从数据库拿入内存。

执行updata sql 时日志的操作

找到行，并更新。
1. 首先更新内存，然后同时将更新提交到redo log中。
2. 此时redo log处于prepare状态，然后告知执行器完成，可以提交事务。
3. 执行器生成binlog、并把binlog写入磁盘
4. 执行器提交事务，更新redo log状态为commit 提交完毕

redo log 两阶段提交:
prepare 和 commit
目的：为了让binlog和redo log逻辑一致
反证：先redo log 后 binlog 。 先binlog 后redo log

redo log 和 binlog 的持久化策略

redo log 有三种写磁盘方式：
参数为0 则是写入缓存区，由主线程来负责一定时间后的写磁盘
参数为 1 则是强制必须写磁盘成功
参数为2 则是只是写缓存区成功。

binlog 也是三种写磁盘。
一般都是设置为1 强制写磁盘成功。

事务没提交时，redolog 会不会写盘？

可能会。
redo log一般有三种状态
1. 事务提交过程中，存在redo log buffer中
2. 事务提交，执行write，进入文件系统的page buffer中
3. 事务提交，执行了fsync，写入磁盘

innodb 有一个后台线程，会每隔1s轮询一次。执行过程是，调用write将redolog buffer中的写入文件系统page buffer中，然后调用fsync写入磁盘。那么一个没有提交的事务，也会被一起持久化。

并行事务提交、redo log buffer占空间一半，后台线程会主动写盘。

undo log

提供回滚和MVCC。
记录的是反逻辑日志。

undo log 事务提交后不能立即删除，因为后续还可能用到undo log。MVCC时候。