MySQL实战优化之InnoDB整体架构

database

一、InnoDB 更新数据得整体架构

每个组件的作用说明:

用一条更新数据来说明每个主键得作用:

update student set name = "zhangsan" where id = 10

1. innodb得重要内存接口:缓冲池(Buffer Pool)

innodb存储引擎中有一个重要得放在内存中得组件,就是缓冲池(Buffer Pool),这里面会缓存很多得数据,以便于以后查询数据得时候,如果在内存缓冲中有数据,就可以直接从内存返回不需要查询磁盘加载到内存缓冲中。

如果InnoDB存储引擎需要执行一条更新语句得时候,比如上面那条数 id = 10 这条数据时候,首先会在缓冲中是否存在 id = 10 这条数据,如果不存在就直接从磁盘中把该条数据加载到缓冲里来,而且会对这条数据加独占锁。

2. undo 日志文件:保证更新后的数据可以回滚

假设 id = 10 这行数据的name原来是 zhangsan, 现在需要更新为 lisi,那么此时需要先把更新的原来的值 name = "zhangsan" 和 id = 10 这些信息,写入到undo日志文件中,如果在后面的操作出现异常,需要做回滚数据就会从undo日志文件中加载回滚。

3. 更新Buffer Pool中的缓冲数据

当我们把要更新的那行数据从磁盘文件加载到缓冲池,同时对该行数据枷锁后把更新前的旧值写入到undo日志文件之后,旧可以正式开始更新这行记录了,先更新缓冲池中的记录,此时这行数据是脏数据。因为磁盘上的依旧是 name 的值是zhangsan,内存中的已经是lisi所以说是脏数据。

4. Redo Log buffer:防止Mysql服务宕机后,保证数据不被丢失。

在buffer pool 中修改了数据后,我们必须把对内存所作的修改写入到一个Redo Log Buffer的内存缓冲区中,这个缓冲区是用于存放redo日志的。所谓的redo日志,就是记录下来对数据做了什么修改,比如对 id = 10 这行记录修改了name字段的值为lisi,这就是一条日志。

在提交事物的时候会将redo日志写入到磁盘中(顺序写入),有一下集中方式写入:

innodb_flush_log_at_trx_commit = 1:不写入磁盘

innodb_flush_log_at_trx_commit = 2:提交事务的时候刷盘

innodb_flush_log_at_trx_commit = 3:写入系统的os再定时刷入磁盘

一般使用的是第二种。

5. binglong日志

binglog日志是mysql server 服务的日志,叫做归档日志,他里面记录的是逻辑行的日志,类似于 对 srtudent 表中的 id = 10 这行数据做了更新操作,更新后的值是什么。

在提交事务的时候需要binglog日志写入到磁盘中,写入的策略如下:

sync_binglog = 0:提交事务时写入系统缓冲在定时刷入磁盘

sync_binglog = 1:提交事务时写入磁盘。

 

总结innodb存储引擎做一次跟新的架构原理:

大家通过一次更新数据的流程,就可以清晰地看到,InnoDB存储引擎主要就是包含了一些buffer pool redo log buffer等内存里的缓存数据,同时还包含了一些undo日志文件,redo日志文件等东西,同时mysqlserver自己还有binlog日志文件

在你执行更新的时候,每条SQL语句,都会对应修改buffer pool里的缓存数据、写undo日志、写redo log buffer几个步骤

但是当你提交事务的时候,一定会把redolog刷入磁盘,binloq刷入磁盘,完成redolog中的事务commit标记;最后后台的1O线程会随机的把buffer pool里的脏数据刷入磁盘里去

 

面试题:

1. 执行更新操作的时候,为什么不精细修改磁盘上的数据?

2. 如果保证msyql服务宕机后数据更新后的数据不丢失?

以上是 MySQL实战优化之InnoDB整体架构 的全部内容, 来源链接: utcz.com/z/535835.html

回到顶部