学习InnoDB：探索核心的旅程
I’ve been using InnoDB for about a decade now, and up to now have understood it well enough to make it do what I wanted, most of the time. However in order to achieve some goals related to efficiency, I’ve found it necessary to take my understanding to the next level. Unfortunately, the InnoDB documentation was pretty lacking in clear explanations of InnoDB’s internal data structures. Reading the code turned out to be the only way to find the information I needed.
我已经使用InnoDB大约十年了，到目前为止，我对它的理解足够深入，以使它能够按照我的意愿工作，大部分时间都是如此。然而，为了实现与效率相关的一些目标，我发现有必要将我的理解提升到一个新的水平。不幸的是，InnoDB的文档在解释InnoDB的内部数据结构方面相当缺乏清晰的说明。阅读代码成为我找到所需信息的唯一途径。
However I quickly found that the structures and their usage (and especially their inter-relationships) are way too complex to keep in your head just based on reading the code. Additionally it’s only really possible to hope you’ve understood the structure correctly just based on reading (and for me, there were a lot of misunderstandings along the way).
然而，我很快发现，这些结构及其使用方式（尤其是它们之间的相互关系）过于复杂，仅仅通过阅读代码是无法将其完全记在脑中的。此外，仅仅通过阅读就能确保自己正确理解结构的可能性实际上是微乎其微的（对我来说，一路上有很多误解）。
An approach I’ve long taken to understanding something that is complex and poorly documented is the following three steps:
我长期以来对于理解复杂且文档不完善的事物采取以下三个步骤的方法：
- Read the existing documentation and the existing code, until a basic understanding is reached. Often there are serious misunderstandings or incorrect factorization at this step.
- 阅读现有的文档和现有的代码，直到达到基本的理解。通常在这一步会出现严重的误解或不正确的分解。
- Write my own implementation, even a very basic and broken one, preferably in a completely different language (which avoids the tendency to cut and paste anything). Revise my understanding based on what works and what doesn’t.
- 编写自己的实现，即使是非常基本和有缺陷的实现，最好使用完全不同的语言（这样可以避免剪切和粘贴任何内容的倾向）。根据工作和不工作的情况修订自己的理解。
- Create new documentation and diagrams based on my new understanding. Refactor my implementation as necessary (the act of reviewing everything in order to document it often reveals incorrect factorizations). Correct documentation based on new understanding from refactoring co...