## 背景 最近发布的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只能读取到小部分有效数据，得不偿失。