MySQL原始碼關於連結串列的實現在ut0lst.h檔案中，其設計思路與常規略有不同，基本思想是指標嵌於物件之內，如下圖所示。

在這種實現方式下，構造一個連結串列需要同時指定物件型別和物件內指標節點的地址。為什麼這麼複雜呢？我們對比一下C++11標準庫中list的實現，發現其就是一個模板類，構造一個list只需要傳入物件型別即可，這更符合我們的理解。研究了下原始碼，也沒找到這樣設計的合理之處。突然想起了MySQL磁碟資料檔案的儲存格式，發現這種設計與其很相符。

簡單來說，MySQL的資料檔案（其實就是一個namespace）被分成了很多extent，每個extent包含64個page，也就是1M。那如何管理這些extent呢？沒256個extent分為一組，每組的第一個page包含了256個extent_entry，每個entry包含64個page的狀態和一個指標node，分別指向前後的entry，跟上面的圖是不是很像？

現在來說一下為什麼要這樣設計。在記憶體中，我們可以使用兩種設計方式：指標嵌於物件之內和物件嵌於節點之內。為什麼C++11中list的實現只需要傳入物件型別就可以呢？因為在程式碼裡面我們可以直接通過符號來獲取prev和next指標的值，那你想想磁碟上面list能這樣做嗎？肯定不行了啊，在磁碟上面我們只能通過地址或偏移來獲取值。

其實上面說了這麼多，總結下來就是一個問題：我們怎麼把list持久化到磁碟中？上面給出了一種很好的實現。

再延伸一個問題：我們怎麼把B+Tree持久化到磁碟中？MySQL索引就是這麼幹的，具體可以在網上找下這方面的介紹。