本文详细介绍了MySQL的InnoDB存储引擎架构，包括其内存结构、数据更新过程、日志含义及区别等内容。深入探讨了缓冲池、重做日志与归档日志的作用及其在事务提交过程中的工作流程。
目录
2.1、InnoDB重要内存结构：缓冲池（Buffer Pool）
1、mysql架构设计
系统采用数据库连接池的方式去并发访问数据库，然后数据库自己其实也会维护一个连接池，其中管理了各种系统跟这台数据库服务器建立的所有连接。
架构包含的组件：SQL接口、SQL解析器、查询优化器、执行器和存储引擎。
其中网络连接必须让线程来处理。
SQL接口：负责处理接收的SQL语句。
SQL解析器：按照SQL语法，对按照SQL语法编写的SQL语句进行解析，理解SQL语句需要做的事情。
查询优化器：选择最优的一条查询路径。
执行器：根据优化器生成的执行计划，不停的调用存储引擎的各种接口完成SQL语句的执行。
存储引擎：就是执行SQL语句，按照一定的步骤 查询内存缓存数据，更新磁盘数据，查询磁盘数据等等。
2、InnoDB存储引擎架构
2.1、InnoDB重要内存结构：缓冲池（Buffer Pool）
作用：查询时如果内存缓冲池里有数据，则不需要查找磁盘。
例如：对“id=10”这一行数据，他其实会先将“id=10”这一行数据看看是否在缓冲池里，如果不在的
话，那么会直接从磁盘里加载到缓冲池里来，而且
还会在缓冲池对这行记录加独占锁
。
2.2、数据更新过程
更新前：先将要更新的那行记录从磁盘文件加载到缓冲池并对其加锁，然后将更新前的旧值写入undo.log中，以便后续回滚。
更新时：
先是会更新缓冲池中的记录，此时这个数据就是脏数据了。然后
对内存所做的修改写入到一个
Redo Log Buffer
里去，这也是内存里的一个缓冲区，是用来存
放redo日志的。
更新后即提交事务：
根据一定策略
把redo.log日志从redo log buffer里刷入到磁盘
里，该策略根据
innodb.flush.log.at.trx.commit来配置，一般配置1即可。并
把这次更新对应的binlog日志写入到磁盘文件中去。
对于binlog日志，其实也有不同的刷盘策略，有一个
sync_binlog
参数可以控制binlog的刷盘策略，一般设置1即可。
只要提交事务成功之后，redo日志一定在磁盘文件里，此时你肯定会有一条redo日志说了，“我此时对哪个数据做了一个什么修改，比如name字段修改为xxx了”。
完成事务提交：
把binlog写入磁盘文件之后，接着就会完成最终的事务提交，此时会把本次更新对应的binlog文件名称和这次
更新的binlog日志在文件里的位置，都写入到redo log日志文件里去，同时在redo log日志文件里写入一个commit标。
后台IO线程随机将内存更新后的脏数据刷回磁盘：
MySQL有一个后台的IO线程，会在之后某个时间里，随机的把内存buffer pool中的修改后的脏数据给刷回到磁
盘上的数据文件里去。
2.3、日志含义
undo.log：将更新前的旧值写入undo.log，便于数据回滚
redo.log： 记录对数据做的修改，
比如对“id=10这行记录修改了name字段的值为xxx”，这
就是一个日志。
bin.log：记录更新后的日志，偏逻辑。
redo.log与bin.log区别
redo log，他是一种偏向物理性质的重做日志，因为他里面记录的是类似这样的东西，“对哪个
数据页中的什么记录
，做了个什么修改”。redo log本身是属于InnoDB存储引擎特有的一个东西。
binlog叫做归档日志，他里面记录的是偏向于逻辑性的日志，类似于“对users
表中的id=10的一行数据
做了更新操作，更新以后的值是什么” ，binlog不是InnoDB存储引擎特有的日志文件，是属于mysql server自己的日志文件。
2.4、InnoDB存储引擎的架构原理
InnoDB存储引擎主要就是包含了一些buffer pool、redo log
buffer等内存里的缓存数据，同时还包含了一些undo日志文件，redo日志文件等东西，同时mysql server自己还有 binlog日志文件。
在你执行更新的时候，每条SQL语句，都会对应修改buffer pool里的缓存数据、写undo日志、写redo log buffer几个步骤；
但是当你提交事务的时候，一定会把redo log刷入磁盘，binlog刷入磁盘，完成redo log中的事务commit标记；最后后台的IO线程会随机的把buffer pool里的脏数据刷入磁盘里去。
扫一扫
2498
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
