image.png
高清流程图地址：https://www.yuque.com/docs/share/243426e2-4b47-4722-ad51-67b01b5d35ae
一、操作触发MySQL服务器执行请求
用户各种操作触发后台sql执行，通过数据库连接池（dbcp,c3p0,druid）与数据库服务器的数据库连接池建立网络连接
数据库连接池中的线程监听到请求后，将接收到的sql语句通过SQL接口响应给查询解析器
查询解析器将sql按照sql的语法解析出查询哪个表的哪些字段，查询条件是啥
再通过查询优化器处理，选择该sql最优的一套执行计划
然后执行器负责调用存储引擎的一系列接口，执行该计划而完成整个sql语句的执行
二、InnoDB存储引擎---缓冲池中完成更新的基本操作
首次更新表中id=1的这条数据时，缓冲池中一开始肯定没有该条数据，先从磁盘中将被更新数据的原始数据加载到缓冲池中
同时为了保证并发更新数据的安全问题，会对这条数据先加锁，防止其他事务进行更新
接着将更新前的值先备份写入到undo log中（便于事务回滚时取旧数据），比如update语句即存储被更新字段之前的值
最后更新缓存页中的数据为最新的数据，至此就完成了在缓冲池中的执行流程
三、redo log和binlog保证事务的可靠性
缓冲池中更新完数据后，需要将本次的更新信息顺序写到redo log 日志以及bin log 日志中（此时信息还在内存中，后续的刷盘策略，为保证数据不丢失会配置双1策略），redo log 落盘后，写bin log 落盘，再将bin log的文件名、文件所在路径信息以及commit标记给同步顺序写到redo log中（以commit标记是否更新到redo log中，是判定事务是否成功提交的一个比较重要的标准），redo log和bin log分别在物理层面为本次事务提供数据上的一致性保障。
四、将事务的操作持久化
前面一系列操作执行成功后，InnoDB存储引擎后台有一个IO线程，会在数据库压力的低峰期间时，将缓冲池中被事物更新、但还没来得及写入磁盘中的数据（脏数据，因为磁盘数据与内存数据不一致）刷到磁盘中，完成事物的持久化。
五、思考
undo log 和 redo log 的作用
undo log保存了事务执行前数据的值，以便于事务回滚时能回到事务执行前的数据版本，多次更新会有undo log的版本链。
redo log在物理层上记录事务操作的一系列信息，保证mysql宕机时还没来得及将数据刷到磁盘里，通过redo log 也能恢复事务提交的数据。
redo log是如何保证事务不丢失的
当一个事务提交成功后，缓冲池中的数据不一定来得及马上落地到磁盘中，但是redo log记录的事务信息持久化到磁盘中了，且含有commit标记，此时如果mysql宕机导致缓冲池中的，已经被事务更新过的内存数据丢了，此时在mysql重启时，将磁盘中的redo log中将事务变更信息给加载到缓冲中，保证事务信息不会丢失。或者redo log刷盘了，binlog写成功了，在重启时会自动给上commit标记，在重放数据
事务是先提交还是先刷盘
事务先提交后刷盘，redo log刷盘成功--》bin log刷盘 --》bin log名称和文件路径信息、commit标志写到redo log中，事务两阶段提交的方式来保证
更新操作为何不直接更新磁盘
直接更新磁盘是随机IO写，存在磁盘地址寻址操作，性能非常低，承载不了高并发场景；
而转换为InnoDB中，内存高速读写、redo log 和 undo log顺序写磁盘性能相对随机IO写性能会高很多，而这种性能上的提高足以抵消这种架构上带来的复杂，可在一定QPS内承载高并发场景
