不建议使用mysql的缓存，如果表有更新那么与表相关联的缓存信息会全部失效。

redo

innodb特有
饭店掌柜记录赊账的🌰 ，先记在小黑板实现快速的记录，在一天不忙的时候再把记录同步到账本上。
四个文件 每个文件1g; 使用write pos 标记写的最后位置，checkpoint 标记提交点的位置。两个指针之间为可写入的空间。

CrashSafe

使用redo log innodb就可以保证数据库在发生异常重启后，之前提交的数据不会丢失，这个能力成为crash-safe.

bin log

Mysql server 自带 通用归档日志

两阶段提交

这里它的2阶段是对应于不同类型的日志，所以两阶段为的就是让这个2个不同的日志做好处理与准备。
1、假设是先写Redo Log，后写binlog。如果这个时候MySQL发生了进程的异常重启，由于Redo Log已经写完，MySQL崩溃之后通过crash_safe能力，能够把数据恢复回来。但是由于binlog还没写完就crash了，所以binlog里面并没有记录该SQL语句，所以使用binlog回档数据的时候，恢复出来的数据其实是少了一次更新操作的，这样就造成了灾难恢复出来的库和原库数据不一致；
2、假设是先写binlog，后写Redo Log。Binlog写完之后发生了crash，由于Redo Log还没有写，崩溃恢复之后这个事务的更新是无效的。但是binlog里面记录了这条更新的语句，所以使用binlog回档的时候就多了一条事务的更新。造成回档出来的数据和原库的数据不一致。
那么两阶段提交就是：
1、prepare阶段，写redo log；
2、commit阶段，写binlog并且将redo log的状态改成commit状态；
mysql发生崩溃恢复的过程中，会根据redo log日志，结合 binlog 记录来做事务回滚：
1、如果redo log 和 binlog都存在，逻辑上一致，那么提交事务；
2、如果redo log存在而binlog不存在，逻辑上不一致，那么回滚事务；
最后大家可发现，这里的两阶段提交，实际是存在与redo log与binlog。所以当未开启binlog，那就是提交事务直接写到redo log里面。这也就是redo log事务两阶段提交，看场景区分的原因。

两阶段提交可以让redo 与 binlog 状态上保持一致
注意：在写入binlog时会找出redo log写入commit标记

区别

1. redo log 是innoDB引擎特有的； binlog是Mysql的Server层实现的，所有引擎都可以使用；
2. redo log 是物理日志，记录的是”在某个数据页上做了什么修改”；binlog是逻辑日志，记录的事这个语句的原始逻辑，比如”给ID=2 这一行的c 字段加1”
3. redo log 是循环写的，空间固定会用完；binlog是可以追加写入的，”追加写”是指binlog文件写到一定大小的时候会切换到下一个，并不会覆盖以前的日志。