MySQL的worklog

作为一款开源软件，MySQL除了在源代码方面进行开源，在其他方面也是做得十分到位。例如文档，在线手册，工作日志，bug系统等等。今天在这里为大家介绍一下MySQL的worklog。

各位可以访问https://dev.mysql.com/worklog/去阅读MySQL的worklog。

每个worklog都会由ID，任务标题，修改时间，版本以及状态构成。点击任务标题即可阅读详细的内容。

在每一个任务的详细内容里面又会包括描述，要求，高层架构和低层设计的内容。每个MySQL的开发工程师就是按照这样的描述和要求进行开发的。我们就以这个任务的内容为例详细解读一下。

这一篇工作日志的标题为“WL#14100: InnoDB: Faster truncate/drop table space”InnoDB快速截断/删除表空间，这是一个很有吸引力的标题，内容描述是什么呢？“当一个表空间被截断或删除时，InnoDB扫描LRU和FLUSH(脏页)列表，并将属于被截断/删除的表空间的所有页面从LRU/FLUSH列表移动到缓冲池空闲列表中。对于> 32G的缓冲池，这种完整的列表扫描会减慢用户线程的行进速度。由于InnoDB不知道一个表空间在缓冲池中有多少页，它将扫描整个列表，即使该表是空的或者缓冲池中只有一个页(或者没有)。如果使用临时表空间池会加剧这个问题。在连接断开时，会导致长时间停机。由于截断临时表空间会重用相同的表空间ID，所以不能使用其他表空间的DROP/CREATE技巧(参见BUG#98869)。为了解决这个问题，我们从WL#11819获得了解决方案，这样它就可以应用到所有的表空间，而不仅仅是UNDO。在删除或截断表空间时，我们将其标记为已删除，删除其文件并向用户报告操作已完成。然后，当我们遇到一个又一个引用这个表空间的页面时，我们将惰性地从缓冲池中释放它们。注意:这并不能解决物理解除大文件链接需要很长时间的问题。这需要一个单独的修复，并需要与运行时团队进行协调。”

看完了上面的一段描述，我们就会知道这个任务是做什么的了，主要是为了实现快速截断/删除表空间，并解释了原因以及打算怎么做。

接下来就提出了要求。

简单明了，4个要求，其中包括三个修复。

1. 修复删除>32G表空间后用户线程的停滞。
2. 修复截断临时表空间的停滞。
3. 修复启用AHI时删除表空间的停滞。
4. 不应增加buf_block_t & but_page_t的大小。

看过了要求，让我们看一下高层架构是什么样的。

“扫描大的LRU和刷新列表时，如果我们可以惰性删除页面和清除AHI条目就没有必要从删除/截断的表空间中删除页面。其思想是当表空间被删除或截断时，在内存数据结构(fil_space_t)中增加表空间中的版本号。今后将引用DVER(删除/截断版本号)。对于一个页面写，进行持久性化时，它必须有一个版本号>= DVER。带有VER < DVER的页将被释放。处理读取要复杂一些。当调用者试图从缓冲池中获取页面时，我们需要检测该页面是否过时。如果页面过期，则释放该页面并强制读取磁盘。这种对所有读取的陈旧页面的检查成本应该非常低，否则它将花费我们从缓冲池中获取每个页面的成本。为了减少陈旧的页面检查开销，我们将在buf_page_t中存储fil_space_t实例的指针。在buf_page_t中嵌入的fil_space_t实例的指针是引用计数的。每次设置buf_page_t::m_space时，都增加fil_space_t中的引用计数。临时表空间和撤销表空间需要这样做，但用户表空间不需要这样做。对于用户表空间，我们执行drop/create操作，这将改变表空间ID，因此我们不能读取被删除或截断的用户表空间。Undo和临时表空间id是缓冲池中较小的一部分，理论上可以重用，因此我们必须确保缓冲池中不存在来自被删除/截断的Undo或临时表空间的任何页。此外，临时表空间在truncate上重用表空间ID(这是非常常见的)，我们必须确保在旧实例的内存被释放之前，从缓冲池中延迟清除任何过时的页面。在处理过期页面时，我们必须处理对刷新的影响。这将在低层设计中得到解释。”高层架构基本上描述了要做的的事情，接下来，更为详细的内容将会在低层设计中描述。

低层设计基本上要到了代码级别的了，里面用注释描述了各个模块实现的功能，感兴趣的可以去翻一翻源代码。

“什么？”源代码里面还没有？，原因是......这部分功能和代码还没有正式发行。在这里透露一个秘密，细心的读者已经发现一部分的工作日志的修改时间是1月份，并且状态为“完成”，而目前MySQL的最新版本8.0.22是2020年10月份发行的。这就意味着，这部分功能和代码将在即将到来的8.0.23版本里面发行，按照惯例，新版本的时间大概会在这周或者下周，赶紧关注一下吧！