data
返回数据行
P
13
redo log commit
1. 非叶子节点只存储主键数据2. 叶子节点之间有指针3. 数据存放在叶子节点中
update sql
更新内存
dump thread
write pos
2
存储引擎层
主键
11
Y
WAL（更新内存，写日志）
7
存储数据，提供读写接口
5
操作存储引擎，返回结果
分析器
B树模型（不合适用来当作索引模型）
check point
1
更新内存中的数据页
io_thread
为什么不能使用bin log来实现崩溃恢复？
从磁盘读入数据页
数据页
relay log
主从延迟的原因：1. 从库所在机器的性能要比主库所在机器的性能差2. 从库压力大，查询耗费大量CPU资源，影响同步速度（最常见，接触的比较多）3. 主库存在大事务，或大表DDL（最常见，接触的比较多）4. 从库的并行复制能力较弱，导致主从延迟
将数据页从磁盘读入内存
每个节点都包含数据，使得单个节点能够容量的主键数量变小，从而使得B树结构更深（磁盘随机寻址次数变多）
写入redo log
第二种：在写入binlog之后突然断电重启，事务没有提交成功，但是bin log就记录更新日志了，磁盘数据页的数据跟bin log不一致
数据
show slave status / sends_behind_master
写入redo log（prepare阶段）
commit
worker 2
主从同步流程（开启并行复制）
写入binlog
2
update sql 执行流程
为什么不能使用redo log进行数据归档？
数据页在内存中
4
N
10
数据页在内存中?
从库
返回数据页
14
事务A事务ID = 2
连接器
启用多线程，加快主从同步速度
worker 1
写入bin log
MySQL基本架构
执行器
MVCC实现逻辑
8
12
worker n
主库
16
优化
coordinator
15
1. statement（逻辑）2. row（物理记录）3. mixed
第二种
第一种
生成执行计划，选择索引
6
redo log处于commit状态（更新完成）
事务B事务ID = 4
3
9
客户端
第一种：在更新内存后MySQL突然断电重启，由于bin log没写入磁盘，就相当于事务提交了，但是崩溃后丢失了
原因
主从同步流程
事务Cup_limit_id = 3
语法分析，词法分析
undo log回滚
如果只有bin log，那么在更新数据的时候，日志写入顺序就只有两种可能：
sql_thread
优化器
相当于原来的sql_thread，但不再直接更新数据，而是只负责读取relay log和分发事务
管理连接，权限验证
Server层
...
指针
存储引擎
work线程是真正执行事务
查询缓存
由于redo log是循环写的，历史日志无法保留，无法起到归档的作用
查询
崩溃恢复是指：数据库异常重启后的数据库状态与使用bin log文件恢复出来数据库状态保持一致
命中直接返回结果
B+树模型（合适用来当作索引模型）
