MySQL笔记
2020-07-06 13:50:12 0 举报
mysql笔记,来源极客时间《MySQL45讲》
作者其他创作
大纲/内容
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+树模型(合适用来当作索引模型)
0 条评论
下一页