MySQL执行路径 和 数据持久化路径。

3. 在内存中修改数据，将旧值存入Undo Log

【客户端发送UPDATE SQL】

7. 正式提交事务

[写入日志]

4. 写入Redo Log Buffer (物理日志)

第二阶段：InnoDB引擎层与事务处理4.1开启事务  默认情况下，每个SQL语句都是一个独立的事务（autocommit=1）。执行器会隐式地开启一个事务。4.2读取数据  o调用 InnoDB 接口，根据 WHERE id = 1 查找记录。  o通过主键索引定位到聚簇索引中的数据页。  o将数据页加载到 Buffer Pool（内存）中（若不在内存中则从磁盘.ibd文件读入到Buffer Pool中）。4.3加锁  o为了满足事务的隔离性，InnoDB会对这行数据加锁。默认的Repeatable Read级别下，会加上一个行级排他锁。    这阻止了其他事务同时修改这一行。4.4生成Undo Log（回滚日志）  o在修改数据之前，InnoDB会先将这行数据的旧版本（修改前内容）拷贝到 Undo Log中。  o实现MVCC（多版本并发控制）：其他正在运行的事务可能还需要读取这行数据的旧版本，    Undo Log为它们提供了“快照”。  oundo log 是逻辑日志4.5修改内存中的数据（Buffer Pool）  oInnoDB在Buffer Pool中，将这行数据的 name 字段修改为 'NewName'。  o标记该数据页为“脏页”（dirty page）。此时，磁盘上的数据还是旧的，但内存中的数据已经更新。     这个在内存中被修改过但还未刷到磁盘的数据页称为“脏页”。4.6生成 redo log（重做日志）—— 先写日志  o执行器通知 InnoDB 存储引擎生成 redo log。  o为了确保事务的持久性，InnoDB会将物理修改信息写入 Redo Log Buffer。    并根据策略（如innodb_flush_log_at_trx_commit）决定是否刷盘。  oRedo Log记录的是“在某个数据页上做了什么修改”，属于物理日志。是顺序写入的，速度很快。  o此时Redo Log还在内存中；处于 prepare 状态（两阶段提交的第一步）5. 准备提交事务 - 两阶段提交（Two-Phase Commit，用于保证 crash-safe）  o当执行 COMMIT（或自动提交）时，进入两阶段提交，这是为了确保 Redo Log 和 Binlog 的逻辑一致性。  oPrepare阶段：将Redo Log Buffer中的内容强制刷盘（fsync）到Redo Log文件。此时，Redo Log被标记为 prepare 状态。  o为什么先写Redo Log？ 因为Redo Log是顺序写，比随机写数据页快得多，并且可以保证即使数据库宕机，数据也不会丢失。6. 写Binlog（MySQL Server 层日志）  oServer层生成这条UPDATE语句对应的 Binlog（二进制日志）。  oBinlog记录的是逻辑日志，即原始的SQL语句（Statement格式）或行变更前后的数据（Row格式）。  o将Binlog写入到文件系统的缓存 binlog cache中，最后调用 fsync 将其刷盘。7. 最终提交事务（COMMIT）  oCommit阶段：在Binlog成功写盘后，InnoDB会将Redo Log中对应事务的记录标记为 commit 状态。  o至此，事务提交完成。

1. 从磁盘或Buffer Pool加载数据页

第三阶段：提交后与后台任务8．释放锁  o事务提交后，释放步骤4.3中为这行数据加的排他锁。9.返回结果  o执行器将更新成功的消息返回给客户端。10. 后台线程异步刷脏页  oBuffer Pool中的脏页不会立刻刷回磁盘，而是由InnoDB的后台线程   在合适的时机（如Buffer Pool空间不足、系统空闲时）通过   Checkpoint 机制，将脏页写入表数据文件（.ibd文件）。  o因为有Redo Log的存在，即使脏页还没刷盘就宕机，重启后也能通过    Redo Log恢复数据。  o这个过程是异步的，不影响事务响应速度。11.Purge操作  后台的Purge线程会清理那些不再被任何事务需要的旧版本的Undo Log记录。

8. Redo Log刷盘 (保证持久性)

[InnoDB引擎层]

[返回结果给客户端]

[优化器] (选择执行计划，是否使用索引等)

- 脏页刷盘 (Checkpoint)- Purge线程清理不再需要的Undo Log

9. 清理Undo Log、释放锁等

5. 准备提交事务

6. 写入Binlog (逻辑日志，用于主从复制)

第一阶段：MySQL Server层处理1.连接器（Connection Handler）  o客户端发起连接，连接器负责身份认证和权限校验。  o如果该用户没有对 users 表的 UPDATE 权限，直接返回错误。  o建立连接会话（session）2.分析器（Parser）  o对 SQL 进行词法分析和语法分析，识别出 UPDATE、users、SET、name、=、'NewName'、    WHERE、id、=、1 这些关键字、表名、列名等。根据MySQL语法规则，判断这条SQL语句是否   符合语法。例如，是否少写了 SET，列名是否存在等。3.优化器（Optimizer）  o确定执行计划，（例如，WHERE id = 1，优化器会判断 id 列是否有索引（比如主键索引），    并决定使用这个索引来快速定位到要更新的那一行。生成最优的执行路径  o如果没有索引，则可能选择全表扫描，但效率极低。4.执行器（Executor）  o首先检查权限（虽然连接器已经检查过，但这里会再次校验操作权限，以防万一）。  o调用 InnoDB存储引擎 的接口，开始执行更新操作。这是核心阶段

[连接器] (管理连接、权限验证)

2. 写入Undo Log (用于回滚和MVCC)

[执行器] (负责具体执行)

[后台线程]

结束

[分析器] (词法分析、语法分析)