MySQL内核月报 2014.08-MariaDB·分支特性·支持大于16K的InnoDB Page Size

背景

最近发布的MariaDB 10.1 Alpha版本，提交了一个改动，放宽了InnoDB Page =16K的限制，将上限提高到64K。 从MDEV-6075需求文档中可以看出，目前只支持COMPACT的结构，DYNAMIC结构能否支持还在研究，COMPRESSED结构则确定无法支持。

业务应用

什么情况下需要64K这么大的页面呢？ 我们知道一个Page，不是所有的page_size都可以用来存数据，还有一些管理信息要存，例如页头和页尾（InnoDB Page）。 此外，InnoDB Buffer Pool管理页面本身也有代价，Page数越多，那么相同大小下，管理链表就越长。

因此当我们的数据行本身就比较长，尤其是做大块插入的时候，更大的页面更有利于提升如速度，因为一个页面可以放入更多的行，每个IO写下去的大小更大，就可以以更少的IOPS写更多的数据。 而且，当行长超过8K的时候，如果是16K的页面，就会强制转换一些字符串类型为TEXT，把字符串主体转移到扩展页中，会导致读取列需要多一个IO，更大的页面也就支持了更大的行长，64K页面可以支持近似32K的行长而不用使用扩展页。 但是，如果是短小行长的随机读取和写入，则不适合使用这么大的页面，这会导致IO效率下降，大IO只能读取到小部分有效数据，得不偿失。

【MySQL从入门到精通】【高级篇】（十二）InnoDB数据存储结构概述 上一篇文章我们介绍了【MySQL从入门到精通】【高级篇】（十一）Hash索引、AVL树、B树与B+树对比。这篇文章接着来介绍InnoDB数据存储结构。
【MySQL从入门到精通】【高级篇】（九）InnoDB的B+树索引的注意事项 上一篇文章我们介绍了聚簇索引，非聚簇索引以及联合索引【MySQL从入门到精通】【高级篇】（八）聚簇索引&非聚簇索引&联合索引。我们在介绍B+树索引的时候，是先把存储用户记录的叶子节点都画出来，然后接着画存储目录记录的内节点，实际上B+树的形成过程不是这样的
db匠 rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/