这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天。
本文以 CC-BY-SA 4.0 发布。
WAL 日志到底是如何保证数据的持久化，宕机后数据不丢失的？相比于其他方案，WAL 日志都有什么优势？
WAL 是 Write-Ahead Logging 的缩写，直译就是提前写入的日志记录。 以 Sqlite 里的实现为例，
传统的撤销日志的实现一般会将原来的内容复制一份放到独立的文件里， 然后直接写入到原来的数据库文件里去，这样就可以保证撤销操作可以顺利进行。
WAL 与之相反。原有的内容会在数据库里保留，而所进行的改动会被写到一个 WAL 文件里去。 事务被提交时，记录只是被写入到 WAL 文件里而已，无需操作原有的数据库文件 ——这样，读操作就可以直接操作原有的数据库文件，无需奇奇怪怪的锁； 而写操作也可以并行进行。
Sqlite 里，将 WAL 写入数据库的操作会定期进行，这种操作叫作一个 checkpoint。 不考虑 checkpoint 时的复制的话，WAL 的一次操作只需要写入一次数据 （而传统做法会写入两份），所以会更加快。
在一些实现里，其实 WAL 也为叫作 redo log， （用 Sqlite 用语）毕竟它反映了将数据库文件从当前 checkpoint 行进到下一个 checkpoint 的记录。
除了 Undo Log 之外，是否还有其他方案可以实现 MVCC？
按维基说法的话， 似乎可以直接写时复制然后再定时清理合并失败的分支。
基于代价的优化器一般需要考虑哪些代价？
找到了一篇挺详尽的文章：基于代价的慢查询优化建议 - 美团技术团队
大概有时间、内存开销、计算量等方面吧？个人感觉的最看重的还是时间。
而对于优化器来说，执行一条SQL有各种各样的方案可供选择，如表是否用索引、选择哪个索引、是否使用范围扫描、多表Join的连接顺序和子查询的执行方式等。
执行器的执行模型，除了本课中提到的火山模型是否还有其他模型？相比于火山模型有什么优劣势？
至少还有一个编译执行。类似 JIT，将 SQL 编译为效率更高的机器码直接执行。
