在上一篇文章中分析了SwitchWAL中一些关键处理点的原因，在SwitchMemtable的流程中同样存在一些难以理解的流程，这里简单分析记录一下原因：
1、为cf切换新的mutable memtable之前为什么要确保当前的active WAL完全未写入数据（即为空WAL）？
这是因为在切换之前，cf的mutable memtable中的数据可能存在于[oldest alive WAL, active WAL]之间的所有WAL中。而当mutable memtable被添加到imm list之前，需要先记录不含有该memtable数据的最老WAL文件号信息（该信息很重要），因此就需要确保当前的active WAL完全未写入数据，该active WAL就是不含有该memtable数据的最老WAL文件。
2、如何确保active WAL完全未写入数据？
1）新创建一个WAL文件，然后设置为DB的active WAL，或者：
2）重命名并打开一个已经被回收的WAL，然后设置为DB的active WAL，或者：
3）当前active WAL本来就还没有写入数据。
3、为什么mutable memtable被添加到imm list之前，记录不含有该memtable数据的最老WAL文件号信息（通过mem_next_logfile_number_字段保存）很重要？
这是因为在对一个cf执行Flush任务时，需要根据PickMemtablesToFlush所选取的所有memtable中的该信息（mem_next_logfile_number_）来计算：含有该cf还未Flush数据的最老的WAL文件号（即cf的OldestLogToKeep信息）。这样当这些选取的memtable被flush到SST之后，所有文件号比OldestLogToKeep小的WAL对该cf来说都是可以安全回收删除的（这也是RocksDB的WAL回收机制）。
4、如何计算cf的OldestLogToKeep？
1）在非mempurge场景下：为cf所pick的所有memtable都是已经按照创建时间升序排序的，因此选取的最后一个memtable的mem_next_logfile_number_即为该cf的最新OldestLogToKeep；
2）在mempurge场景下：则在pick的过程计算所pick的memtable中的最大mem_next_logfile_number_即可。
