MySQL通过Redo Log落盘、binlog与Redo Log的两阶段提交机制及合理配置保障事务持久性：事务提交时先将修改写入Redo Log并刷盘，确保崩溃后可通过重放日志恢复数据；启用binlog时采用2PC，Prepare阶段写Redo Log并标记，Commit阶段写binlog并通知InnoDB完成提交，保证日志一致性；配合innodb_flush_log_at_trx_commit=1和sync_binlog=1可实现强持久性，即使系统崩溃也不会丢失已提交事务的数据。
MySQL 事务的持久性是指：一旦事务提交，其所做的修改就会永久保存到数据库中，即使系统崩溃也不会丢失。持久性是 ACID 特性中的“D”（Durability），它的实现依赖于 MySQL 的存储引擎机制和底层日志系统。
利用重做日志（Redo Log）保障持久性
MySQL 的 InnoDB 存储引擎通过 重做日志（Redo Log） 来保证事务的持久性。当事务提交时，InnoDB 会先将事务的修改操作写入 Redo Log，并确保这些日志被刷新到磁盘（由参数 innodb_flush_log_at_trx_commit 控制），之后才认为事务真正提交成功。
关键点：
- Redo Log 是物理日志，记录的是数据页的修改细节。
- 写入 Redo Log 是顺序写，比直接刷脏页到磁盘快得多。
- 崩溃恢复时，InnoDB 会重放 Redo Log 中已提交但未写入数据文件的操作，确保数据不丢失。
二阶段提交（2PC）确保日志一致性
在启用了 binlog 的情况下，MySQL 使用 两阶段提交 机制协调 Redo Log 和 binlog，以保证它们的一致性，从而加强持久性保障。
流程如下：
- Prepare 阶段：InnoDB 将事务的 Redo Log 写入并标记为 prepare 状态，同时确保日志落盘。
- Commit 阶段：MySQL Server 将该事务的 binlog 写入并同步到磁盘，然后通知 InnoDB 提交事务，InnoDB 才将 Redo Log 标记为 commit。
这种机制确保了即使在崩溃后重启，系统也能根据 binlog 和 Redo Log 的状态恢复或回滚事务，避免数据不一致。
关键配置参数影响持久性强度
以下参数直接影响持久性的强弱和性能之间的权衡：
- innodb_flush_log_at_trx_commit = 1：每次事务提交都强制将 Redo Log 刷到磁盘（默认值，最安全）。
- sync_binlog = 1：每次事务提交都将 binlog 同步到磁盘，配合 2PC 提供强持久性。
- 若设置为 0 或大于 1，则可能在崩溃时丢失最近几秒的事务，但性能更高。
数据文件刷新与检查点机制
InnoDB 不会在事务提交时立即把数据页写回磁盘，而是通过后台线程异步刷盘。但 Redo Log 已经记录了变更，因此即使数据页还没刷，只要日志已持久化，系统恢复时就能重建数据。
检查点（Checkpoint）机制会定期清理已不再需要的 Redo Log，同时推动脏页刷新，平衡性能与恢复效率。
基本上就这些。MySQL 通过 Redo Log 落盘、binlog 与 Redo Log 的两阶段提交、以及合理的配置，共同保障事务的持久性。只要日志不丢，数据就不会丢。
