1.redolog将数据记录更新到磁盘的过程，也就是推进checkpoint的过程
在系统不忙的时候，将数据从磁盘读取到内存（如果要刷盘的数据页不在内存），然后用redolog里的记录更新内存，然后写入到磁盘
2.为什么说MyISAM没有crash-safe的能力，binlog不能用来做崩溃回复吗？
[TODO] 异常重启后，MyISAM是放着不管的，下次使用数据的时候提示“表损坏，需要恢复”，不能恢复的原因见第15篇
3.binlog逻辑日志和redolog物理日志有啥区别
[TODO] 见第15篇和23篇
4.commit后做了两个动作，把WAL文件持久化到磁盘，然后更新数据库（磁盘记录）。是否是完成WAL持久化到磁盘，然后才将更新数据库和索引的记录到磁盘？
是。并且更新的数据写到磁盘是后台操作。
5.为什么使用WAL能解决直接更新数据到磁盘IO成本高的问题？
使用WAL，事务commit直接写数据到磁盘比写日志的顺序IO成本高，WAL顺序IO性能高一些。
6.如果用binlog做断电恢复，没写log的不提交，回滚操作用undolog实现，redolog是否没必要存在
[TODO] undolog是依赖redolog来恢复的，没有redolog，undolog就不完整。见第3篇
7.2PC的过程如果binlog写完后Mysql故障重启了，binlog和redolog是否就不一致了，会导致用binlog恢复的数据库数据和当前数据库不同？
不会，这种情况重启后会提交事务。redolog记录里有事务id，如果在binlog里能找到对应的事务，redolog就提交
8.在一个大事物或长事物里，一边执行sql一边写redo log吗？未提交的事物也会写到redo log file吗？
会先写一块内存，叫做log_buffer里面，在提交的时候再一次性写到磁盘
9.innodb结构为内存池和后台线程 ， 其中内存池里存在redo日志缓冲 和 缓冲池，其中缓冲池以页为单位缓冲磁盘数据 。
（1）更新语句时执行器调用innodb存储引擎先从内存读数据，指的就是从innodb缓存池中读取数据，没有的话就去读取磁盘找， 找到后再同步到缓冲池。
（2）Server层的查询缓存和innodb的缓冲池不是一个东西
10.备份也是有锁的，特别是myisam引擎
[TODO] 见第6篇
11.高并发地插入数据，有哪些情况下会导致数据库插入变慢。
（1）redolog和binlog会有影响
（2）[TODO] 锁的影响大一些
12.redolog和binlog是在内存中还是在磁盘中？如果在内存和在磁盘上都有怎么保证突然断电时的一致性？
[TODO] redolog有redolog buffer，binlog有binlog cache。保持数据可以看第15篇和第23篇
13.两阶段提交是原子性的吗？
不是。如果是原子性的就不用两阶段提交了。
14.如果更新语句涉及到索引，索引是什么时候被更新的，是否跟数据一样，都是先更新内存，再更新磁盘？
索引也是数据的一部分，是一样的策略
15.事务失败回滚是否也会写redolog和binlog，回滚涉及索引更细的话，如何更新索引？
会写redolog，打上回滚标签，binlog直接丢弃。[TODO] 回滚都是直接把没用的内存版本删除。
16.如果redolog写满，需要停下来将数据写入磁盘。这时候整个数据库处于阻塞状态吗？当有大量数据涌入，存在数据丢失的风险吗？
更新会被堵住。但是不算数据丢失，因为事务提交不了。数据丢失的定义是本该存在的数据没了，但是这时候并没有告知客户端事务成功，就不算丢失。
17.update是先写redolog，再把数据写内存，那么写入的这条数据在内存中的驻留时间是怎么处理的？是redo log写入磁盘后从内存中删除吗？
不会删除，除非内存不够用，不过在从内存删除之前会保证持久化到磁盘。这里说的应该是redolog buffer。
数据在内存中的驻留时间涉及到innodb buffer pool的设计，不活跃的数据页可能被淘汰。
18.2PC的过程，如果redolog 处于prepared状态时数据库崩溃后恢复，存储引擎发现写了redolog，但是没写binlog，存储引擎会把事务回滚。
如果一个更新语句，写到存储引擎的redolog，而且状态是已提交，还没来得及同步到磁盘数据区。
这时，如果来一个查询，此条数据，是会查询出来的对吧。 那么这时候的查询流程是什么样子的，每次会先到redolog里查询下，有没有数据，因为redolog也是磁盘文件，这是效率会高吗？
这条数据大概率还在innodb的buffer pool，直接从内存返回。[TODO] 如果内存页已经被淘汰，执行的流程是什么样的？
19.2PC的过程，redolog处于prepared的状态时数据库故障重启了，数据是一致的吗
重启回来之后这个事务会回滚。binlog中没有这条记录的操作，用binlog恢复的数据和原数据库是一致的。
20.2PC的过程，binlog写入了，redolog未提交，此时我断开连接，这个事务应该是失败的。按照上面的说法，恢复的时候binlog这一条记录存在了，所以这条记录应该存在。这是mysql的bug？
此时你主动断开连接，这个事务就是“异常”，而不是“失败”。异常的事务，状态可能是提交，也可能是未提交，所以记录存在，是合理状态的一种
21.innodb_flush_log_at_trx_commit 和 sync_binlog 都设置成1，那么都是每个事务结束直接写磁盘，那是不是就浪费了WAL的作用，这样每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高。
wal可以提升事务提交的性能，因为是顺序写。
22.2PC在redologprepared已经把redolog刷到磁盘了