企业官网建设流程全解析

以

UPDATE test SET a=1 WHERE id=2

为例，完整讲解执行流程。

一、核心概念速记

在开始之前，你需要记住三个日志文件的作用：

• undo log：用于事务回滚，记录数据修改前的旧值
• redo log：用于崩溃恢复，记录数据修改后的新值
• binlog：用于主从复制和数据恢复，记录所有数据变更

二、执行步骤详解

第一步：记录undo log（事务准备阶段）

事务开始时，MySQL会先记录undo log。

操作：UPDATE test SET a=1 WHERE id=2 undo log记录： ┌─────────────────────┐ │ 操作类型：UPDATE │ │ 表名：test │ │ id = 2的旧值：a=0 │（假设原来a的值是0） └─────────────────────┘

为什么需要undo log？

如果你执行了UPDATE，然后想回滚（ROLLBACK），MySQL就用undo log里的旧值把数据改回去。

BEGIN; UPDATE test SET a=1 WHERE id=2; -- undo log记录 a原来是0 ROLLBACK; -- 用undo log把a改回0

第二步：写redo log（prepare阶段）

undo log记录完后，存储引擎（InnoDB）会写入redo log，并标记状态为prepare。

redo log内容： ┌──────────────────────────────────┐ │ 操作类型：UPDATE │ │ id=2, a=1（新值） │ │ 状态：prepare（准备中） │ └──────────────────────────────────┘ ↓ (立即刷入磁盘) 磁盘中的redo log file

这一步的意义：

• 保证即使系统崩溃，通过redo log也能恢复数据
• 只有写到磁盘的redo log才真正安全
• 状态是prepare，说明还没有最终提交

第三步：获取行锁并修改数据（执行阶段）

写完redo log后，MySQL获取行锁，在内存中修改数据。

步骤流程： 1. 获取id=2这一行的行锁 ↓ 2. 从磁盘读入内存（buffer pool） - 读到：id=2, a=0（旧值） ↓ 3. 在内存中修改 - 改为：id=2, a=1（新值） ↓ 4. 标记为脏页（dirty page） - 说明这个数据页的内存版本和磁盘版本不一致

注意：此时数据还在内存中，没有写入磁盘！

这是InnoDB的优化策略：

• 立即写磁盘很慢（每次都做磁盘IO）
• 先在内存中修改，标记为脏页
• 后台有线程在适当时机将脏页刷入磁盘

第四步：写入binlog（服务层记录）

binlog是MySQL服务层维护的日志，不是存储引擎的。

在事务提交前，MySQL会将操作写入binlog。

binlog内容： ┌──────────────────────────────────┐ │ UPDATE test SET a=1 WHERE id=2 │ │ 时间戳：2025-01-07 10:30:00 │ │ 连接ID：12345 │ └──────────────────────────────────┘ binlog主要用途： 1. 主从复制：从库读主库的binlog来同步数据 2. 数据恢复：结合备份文件，恢复到某个时间点

第五步：提交事务（commit阶段）

这是关键的一步！包含两个操作：

操作1：修改redo log状态为commit

redo log状态变化： prepare → commit redo log： ┌──────────────────────────────────┐ │ 操作类型：UPDATE │ │ id=2, a=1 │ │ 状态：commit（已提交） │ └──────────────────────────────────┘ 立即刷入磁盘

操作2：释放行锁

操作完成，释放id=2这一行的锁 其他事务现在可以修改id=2的数据了

三、两阶段提交（Two-Phase Commit）

这是确保redo log和binlog一致性的机制，也是为什么MySQL的可靠性这么高的原因。

第一阶段（Prepare）： ↓ redo log写入磁盘，状态=prepare ↓ 不能立即提交，要等binlog写完 第二阶段（Commit）： ↓ binlog写入磁盘 ↓ redo log状态改为commit，写入磁盘 ↓ 事务最终完成

为什么要这样设计？

假设没有两阶段提交：

场景1：只写redo log不写binlog

UPDATE执行了 → 主库数据改了 → 从库没收到 →主从数据不一致！

场景2：只写binlog不写redo log

UPDATE执行了 → binlog记录了 →系统崩溃 → 无法恢复数据！

两阶段提交保证：

• 要么redo log和binlog都成功，数据最终一致
• 要么都失败，系统可以恢复到之前的状态

四、崩溃恢复场景

如果在commit阶段崩溃了怎么办？

假设：redo log已经写入（prepare），binlog已经写入， 但redo log的commit状态还没写入磁盘就崩溃了 MySQL重启后： 1. 扫描redo log 2. 看到这个操作状态是prepare 3. 查看binlog中是否有对应的操作记录 4. 如果binlog中有，说明操作已经完成，就把redo log改为commit 5. 如果binlog中没有，说明操作没完成，就回滚这个操作

五、完整时间线总结

UPDATE test SET a=1 WHERE id=2 执行过程： 时间点1：事务开始 → 记录undo log（id=2, a原来的值） 时间点2：执行阶段 → 写redo log（prepare状态） → 获取行锁 → 在buffer pool中修改数据为a=1 → 标记为脏页 时间点3：提交阶段开始 → 写binlog（用于主从复制） 时间点4：提交阶段完成 → 修改redo log状态为commit → 释放行锁 → 事务完成！ 时间点5：后台线程（不一定立即） → 将脏页刷入磁盘 → 如果故障恢复需要，redo log可以帮忙恢复

六、需要理解：

1. 为什么INSERT/UPDATE/DELETE很慢？

   • 因为要做这么多事：写undo log、写redo log、写binlog、获取锁、修改数据、提交事务
   • 所以：批量操作用batch比逐条执行快得多

2. 为什么MySQL这么可靠？

   • 多层日志保护（undo log、redo log、binlog）
   • 两阶段提交确保数据一致性
   • 即使系统崩溃也能恢复

3. 主从复制为什么会延迟？

   • 因为从库是从主库的binlog读取数据
   • 主库写完数据后，从库需要网络传输、解析、执行
   • 这之间有延迟

4. 数据库性能优化的角度：

   • redo log的大小和io_capacity参数很重要
   • 批量操作时用事务分组，减少提交次数
   • 避免频繁的小事务