MySQL通过InnoDB的redo log实现WAL机制，先写日志后改数据，提升写性能并保障崩溃恢复。
MySQL 本身并不直接使用 WAL（Write-Ahead Logging）这个术语，但其核心机制 InnoDB 存储引擎的实现中，本质上遵循了 WAL 的设计思想。WAL 的全称是“预写日志”，它的核心原则是：在对数据页进行修改之前，必须先将修改操作记录到持久化日志中。
什么是 WAL 机制
WAL 是数据库系统中用于保证持久性和原子性的重要技术。它的基本流程是：
- 当执行一条更新语句时，不会立刻修改磁盘上的数据文件。
- 而是先把这次修改的“动作”写入一个顺序追加的日志文件（如 InnoDB 的 redo log）。
- 等日志成功落盘后，才允许认为事务的修改已持久化。
- 实际的数据页更新可以异步进行，比如通过后台线程逐步刷回磁盘。
这样做的好处是：日志是顺序写，比随机写数据页快得多，从而大幅提升写性能。
InnoDB 中的 WAL 实现：redo log
InnoDB 使用 redo log 来实现 WAL 机制。redo log 是一种物理日志，记录的是“哪个数据页做了什么修改”。
典型流程如下：
- 事务执行 UPDATE 操作，InnoDB 将修改先写入内存中的数据页（buffer pool），同时生成对应的 redo log 记录。
- redo log 被写入 redo log buffer，并在事务提交时根据策略（如 innodb_flush_log_at_trx_commit）刷到磁盘。
- 只要 redo log 落盘，即使此时 MySQL 崩溃，重启后也能通过重放 redo log 恢复未写入磁盘的数据页。
redo log 是固定大小、循环写入的。它确保了即使 buffer pool 中的脏页还没来得及刷盘，也不会丢失已提交事务的数据。
WAL 如何提升性能与保障安全
WAL 在 InnoDB 中解决了两个关键问题：
- 性能优化：把随机写（数据页）转化为顺序写（redo log），极大减少磁盘 I/O 开销。
- 崩溃恢复：通过重放 redo log，确保已提交事务的修改不会因宕机而丢失，满足持久性要求。
注意：WAL 只保证修改记录先于数据落盘，不负责事务的隔离或回滚。回滚依赖 undo log，而 WAL 主要服务于 redo log 的持久化路径。
与其他日志的区别
MySQL 中有多种日志，不要混淆：
- redo log：存储引擎层，InnoDB 特有，实现 WAL，用于崩溃恢复。
- binlog：Server 层，记录所有事务的逻辑操作，用于主从复制和 PITR（时间点恢复）。
- undo log：用于事务回滚和 MVCC，不属 WAL 范畴。
在事务提交时，InnoDB 采用“两阶段提交”协调 redo log 和 binlog，确保两者一致性。
基本上就这些。MySQL 的 WAL 机制虽不显式提，但通过 InnoDB 的 redo log 深度融入其架构，是高性能与高可靠的基础之一。
