## 背景 最近發布的MariaDB 10.1 Alpha版本，提交了一個改動，放寬了InnoDB Page<=16K的限制，將上限提高到64K。 從MDEV-6075需求文檔中可以看出，目前只支持COMPACT的結構，DYNAMIC結構能否支持還在研究，COMPRESSED結構則確定無法支持。 ~~~ revno: 3987 committer: Jan Lindstr?m <jplindst@mariadb.org> branch nick: 10.1 timestamp: Tue 2014-05-13 13:28:57 +0300 message: MDEV-6075: Allow > 16K pages on InnoDB This patch allows up to 64K pages for tables with DYNAMIC, COMPACT and REDUNDANT row types. Tables with COMPRESSED row type allows still only <= 16K page size. Note that single row size must be still <= 16K and max key length is not affected. ~~~ ## 業務應用 什么情況下需要64K這么大的頁面呢？ 我們知道一個Page，不是所有的page_size都可以用來存數據，還有一些管理信息要存，例如頁頭和頁尾（[InnoDB Page](https://raw.githubusercontent.com/jeremycole/innodb_diagrams/master/images/InnoDB_Structures/Basic%20Page%20Overview.png)）。 此外，InnoDB Buffer Pool管理頁面本身也有代價，Page數越多，那么相同大小下，管理鏈表就越長。 因此當我們的數據行本身就比較長，尤其是做大塊插入的時候，更大的頁面更有利于提升如速度，因為一個頁面可以放入更多的行，每個IO寫下去的大小更大，就可以以更少的IOPS寫更多的數據。 而且，當行長超過8K的時候，如果是16K的頁面，就會強制轉換一些字符串類型為TEXT，把字符串主體轉移到擴展頁中，會導致讀取列需要多一個IO，更大的頁面也就支持了更大的行長，64K頁面可以支持近似32K的行長而不用使用擴展頁。 但是，如果是短小行長的隨機讀取和寫入，則不適合使用這么大的頁面，這會導致IO效率下降，大IO只能讀取到小部分有效數據，得不償失。