InnoDB通过Redo Log和Undo Log实现事务的持久性、原子性和隔离性，其中Redo Log用于崩溃恢复，Undo Log支持回滚与MVCC；而MyISAM、Memory等非事务引擎不支持事务日志，仅InnoDB等事务型引擎具备完整日志机制；合理配置innodb_log_file_size和innodb_flush_log_at_trx_commit可平衡性能与数据安全。
MySQL的存储引擎与事务日志之间存在紧密联系，尤其在支持事务的引擎中，事务日志是实现数据持久性、原子性和一致性的重要机制。理解它们之间的关系，有助于优化数据库性能和保障数据安全。
事务日志的作用
事务日志（Transaction Log）记录了所有对数据库进行修改的操作，如INSERT、UPDATE、DELETE等。它的主要作用包括：
- 保证事务的持久性：即使系统崩溃，已提交的事务也能通过日志恢复。
- 支持回滚操作：未提交的事务可以通过回滚日志（Undo Log）撤销更改。
- 提升写入性能：采用预写日志（WAL, Write-Ahead Logging）机制，先写日志再写数据文件，减少磁盘随机I/O。
InnoDB引擎与事务日志
InnoDB是MySQL中最常用的事务型存储引擎，其事务日志主要包括两种：
- 重做日志（Redo Log）：记录物理页面的修改，用于崩溃恢复。Redo Log写入是顺序的，效率高，且在事务提交时刷盘，确保持久性。
- 回滚日志（Undo Log）：记录事务执行前的数据状态，用于MVCC（多版本并发控制）和事务回滚。Undo Log保存在系统表空间或独立的undo表空间中。
InnoDB通过Redo Log实现持久性，通过Undo Log实现原子性和隔离性。Redo Log文件通常命名为ib_logfile0和ib_logfile1，大小固定且循环写入。
其他存储引擎的日志机制
并非所有存储引擎都支持事务和事务日志：
- MyISAM：不支持事务，因此没有Redo或Undo日志。它只有二进制日志（Binary Log），但属于Server层日志，不用于崩溃恢复。
- Memory：数据存于内存，不支持事务日志，重启后数据丢失。
- Archive：仅支持INSERT和SELECT，无事务支持，也无事务日志。
只有事务型存储引擎（如InnoDB）才具备完整的事务日志体系。
事务日志配置与调优建议
合理配置事务日志能显著影响数据库性能和可靠性：
- 调整Redo Log大小：过小会导致频繁检查点，增大I/O压力；一般建议设置为1～2GB（通过innodb_log_file_size配置）。
- 控制刷盘策略：通过innodb_flush_log_at_trx_commit参数控制日志刷盘频率。值为1时最安全（每次提交都刷盘），0或2可提升性能但牺牲一定持久性。
- 启用独立Undo表空间：便于管理和回收Undo空间，提升大事务处理能力。
基本上就这些。InnoDB通过Redo和Undo日志构建了完整的事务支持体系，而其他非事务引擎则不具备这类机制。理解这一点，有助于在选型和调优时做出更合理的决策。
