标签：存储 Log 更新 剖析 InnoDB 执行 Redo

InnoDB存储引擎执行原理深度剖析

Mysql架构和InnoDB存储引擎-流程图解析

前台操作触发Mysql服务器执行请求

前台用户各种操作触发后台sql执行，通过web项目中自带的数据库连接池：如dbcp、c3p0、druid等，与数据库服务器的数据库连接池建立网络连接；

数据库连接池中的线程监听到请求后，将接收到的sql语句通过SQL接口响应给查询解析器，查询解析器将sql按照sql的语法解析出查询哪个表的哪些字段，查询条件是啥；再通过查询优化器处理，选择该sq最优的一套执行计划，然后执行器负责调用存储引擎的一系列接口，执行该计划而完成整个sql语句的执行，如下图所示：

InnoDB存储引擎-缓冲池中完成更新的基本操作

具体执行这些执行计划得要存储引擎来完成，如图所示，首次更新users表中id=10的这条数据，缓冲池中一开始肯定没有该条数据的，得要先从磁盘中将被更新数据的原始数据加载到缓冲池中（这里涉及到的innodb buffer暂时不讲）。

同时为了保证并发更新数据安全问题，会对这条数据先加锁，防止其他事务进行更新。
接着将更新前的值先备份写入到undo log中（便于事务回滚时取旧数据），比如update语句即存储被更新字段之前的值。
最后更新缓存页中的数据为最新的数据，至此就完成了在缓冲池中的执行流程，如下图所示：

Redo Log和BinLog保证事务的可靠性

缓冲池中更新完数据后，需要将本次的更新信息顺序写到Redo Log日志以及Binlog日志中（此时信息还在内存中，后续的刷盘策略如图所示），一般我们为了保证数据不丢失会配置双1策略，Redo Log落盘后，写Binlog落盘，再将Binlog的文件名、文件所在路径信息以及commit标记给同步顺序写到Redo log中（其中以commit标记是否更新到Redo Log中，是判定事务是否成功提交的一个比较重要的标准），Redo Log和BinLog分别在物理和逻辑层面为本次事务、提供数据上的一致性保障，如下图所示：

将事务的操作持久化

前面一些列操作执行成功后，InnoDB存储引擎后台有一个IO线程，会在数据库压力的低峰期间时如凌晨时分，将缓冲池中被事务更新、但还没来得及写到磁盘中的数据（脏数据，因为磁盘数据和内存数据已经不一致了）给刷到磁盘中，完成事务的持久化，如下图所示：

标签：存储,Log,更新,剖析,InnoDB,执行,Redo
来源： https://blog.csdn.net/zhougubei/article/details/121080190

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。