redo log 保证持久性，记录物理页修改；undo log 保证原子性和一致性，记录逻辑逆操作；二者写入时机、生命周期及层级均不同。
redo log 和 undo log 都是 InnoDB 存储引擎实现事务特性的核心日志，但它们作用完全不同、记录内容不同、写入时机不同、存储形式也不同。
作用目标不同
redo log 保证事务的持久性：只要事务提交成功，即使数据库突然宕机，重启后也能通过 redo log 把已提交但还没刷盘的修改“重做”一遍，确保数据不丢失。
undo log 保证事务的原子性和一致性：事务执行中每条修改前，先记下旧值；若事务中途回滚，就用 undo log 把数据“撤销”回原来的样子；同时它还支撑 MVCC，让其他事务能读到历史快照版本。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
记录内容和格式不同
redo log 是物理日志，记录的是“哪个数据页、哪个偏移量、被写入了什么新值”，比如“页号 123，偏移量 48，写入 0xABCDEF”。它不关心 SQL 逻辑，只管底层页面变化。
undo log 是逻辑日志，记录的是“对哪一行做了什么操作的逆操作”，比如“事务 T 插入了一行，那 undo log 就记一条对应的 DELETE；T 更新了 name 字段，undo log 就记一条把 name 改回旧值的 UPDATE”。它面向行、可读性强，但不直接对应磁盘页结构。
写入与生命周期不同
- redo log 在数据修改前就写入缓冲区（WAL 机制），事务提交时必须确保这部分日志已落盘（取决于 innodb_flush_log_at_trx_commit 设置）；日志文件循环使用，空间满则覆盖最老记录。
- undo log 在事务开始修改数据时同步生成，并随事务持续追加；事务提交后不会立刻删除，要等所有依赖该版本的快照读事务都结束后，才由 purge 线程异步清理。
所属层级与适用范围不同
两者都是 InnoDB 引擎层日志，只对 InnoDB 表生效。而 binlog 是 MySQL Server 层日志，与存储引擎无关，用于主从复制和归档。redo log 和 undo log 不对外暴露，也不参与复制；binlog 才是跨引擎、跨实例的数据同步基础。
