mysql架构总结

插入一个值A

redo日志文件

描述数据

值A

一行数据

表id

数据页放在前面缓存页放在后面

undo log日志类型

最大记录最小记录

开始节点

日志结构

数据页

描述数据(冷数据区域）

加载数据页到Buffer Pool

Buffer Pool缓冲池

读取roll_pointer指向的下一条

数据页头

缓存页

roll_pointer

head

包含很多数据页

后台线程

1、缓存数据

结束节点

redo log 磁盘文件

事务A

准备提交事务时redo log写入os cache 每隔一秒定时写入磁盘该模式只有当参数 innodb_flush_log_at_trx_commit=2时才生效

trailer

是(说明该事务已调提交)

读取该条数据

innoDB存储引擎

chunk

数据页缓存hash表

body

是

redo log block

否(说明该事务已提交)

值A修改为B

8、刷入磁盘

7、写入binlog文件位置和commit标记

获取脏数据

写入

txr_id=58

表空间号+数据页号=缓存页地址

内存

用来存储需要刷回磁盘的缓存页的描述数据

实际结构

事务Atrx_id=50

ReadView

undo log开始位置

磁盘文件

MVCC多版本并发控制机制

是(说明该跳数据是和当前事务并发进行的事务产生的)

数据页目录

值B修改为C

定时写入

trx_id小于min_trx_id

多个数据行

否(说明该条数据是在当前事务之后的事务产生的）

Buffer Pool

数据区64个数据页

是（说明该条数据是自己产生的）

值C

txr_id=69

trx_id是否在min_trx_id和max_trx_id之间

3、更新缓存数据

主键<列长度，列值>

min_trx_idm_ids里最小的事务id

flush链表基础节点

执行器

系统崩溃后可以通过redo log 来恢复之前的修改

2、写入数据的旧值便于回滚（写入undolog）

事务Btrx_id=58

insert语句对应的undo log日志结构

写入时机

max_trx_id下一个事务要生成的事务id，也就是最大事务id

free链表基础节点

值B

bin log 日志文件

否

一组数据区256个数据区

起点

4、写redo日志

存储格式

m_ids此时在Mysql里执行，还未提交的事务id

6、准备提交事务 binlog日志写入磁盘

文件末尾

5、准备提交事务时redolog刷入磁盘

creator_trx_id=txr_id

描述数据(热数据区域）

定时刷新

读取

（1）如果写入redo log buffer的日志已经占据了redo log buffer总容量的一半了，也就是超过了8MB的redo log在缓冲里了，此时就会把他们刷入到磁盘文件里去（2）一个事务提交的时候，必须把他的那些redo log所在的redo log block都刷入到磁盘文件里去，只有这样，当事务提交之后，他修改的数据绝对不会丢失，因为redo log里有重做日志，随时可以恢复事务做的修改（PS：当然，之前最早最早的时候，我们讲过，这个redo log哪怕事务提交的时候写入磁盘文件，也是先进入os cache的，进入os的文件缓冲区里，所以是否提交事务就强行把redo log刷入物理磁盘文件中，这个需要设置对应的参数，我们之前都讲过的 ，大家回过头去看看 ）（3）后台线程定时刷新，有一个后台线程每隔1秒就会把redo log buffer里的redo log block刷到磁盘文件里去（4）MySQL关闭的时候，redo log block都会刷入到磁盘里去

准备提交事务时bin log写入 os cache 每隔一秒定时写入磁盘该模式只有当参数sync_binlog=0时生效

txr_id=50

Redo Log Buffer

trx_id在m_ids中

undo log空的

undo log日志编号

undo日志文件

文件头

事务Ctrx_id=69

undo log 版本链

undo log结束位置

很多数据行

os cache

LRU链表基础节点

数据页默认大小16K

Buffer Pool通过innodo_buffer_pool_size控制

后台IO线程

Buffer Pool这个内存数据结构

1、执行一个事务生成ReadView