事务的四大特性主要是是acid，分别是原子性A、一致性C、隔离性I和持久性D。其原子性是 通过这个undolog 来保证的，持久性是 通过redolog 来实现的，隔离性是通过事务的 读写锁+mvcc机制 来实现的。在这四大特性中，一致性C是最重要的，只有其他三个实现了，才有可能实现这个一致性，即 一致性是最终目的，其他三个就是实现的手段 。
定义
- Binlog（二进制日志）：Binlog是在事务提交时被写入的。当事务提交时，相关的更改操作将被记录到binlog中，以确保binlog中包含了所有已提交的更改，用于数据恢复、数据复制和数据同步等操作。
- Redo log（重做日志）：Redo log是在事务提交时被写入的。当事务提交时，其对数据库的更改会首先写入重做日志，然后再将更改应用到内存和磁盘上的数据页上。这样可以确保在数据库发生异常宕机时，可以通过重做日志来恢复已经提交的事务数据，保证事务的持久性与数据的一致性。
- Undo log（回滚日志）：Undo log是在事务执行时被写入的。当事务执行时，其对数据库的更改会首先写入undo log，然后再将更改应用到内存和磁盘上的数据页上。这样可以确保在事务回滚或者发生异常时，可以通过undo log来回滚事务对数据库的更改，保证数据库的一致性。
刷盘时机
binlog
sync_binlog
- 0：每次提交事务binlog不会马上写入到磁盘，而是先写到page cache。不去强制要求，由系统自行判断何时写入磁盘，在Mysql 崩溃的时候会有丢失日志的风险；
- 1：每次提交事务都会执行 fsync 将 binlog 写入到磁盘；
- N：每次提交事务都先写到page cache，只有等到积累了N个事务之后才 fsync 将 binlog 写入到磁盘，在 MySQL 崩溃的时候会有丢失N个事务日志的风险。
redo log
innodb_flush_log_at_trx_commit
- 0（延迟写） ：表示每次事务提交时都只是把 redo log 留在 redo log buffer 中，开启一个后台线程，每1s刷新一次到磁盘中
- 1（实时写，实时刷） ：表示每次事务提交时都将 redo log 直接持久化到磁盘，真正保证数据的持久性
- 2（实时写，延迟刷） ：表示每次事务提交时都只是把 redo log 写到 page cache，具体的刷盘时机不确定
innodb_log_buffer_size
redo log buffer 占用到了 innodb_log_buffer_size 设置的值一半，也会把redo log buffer中的数据刷盘
