[翻译] InnoDB 页合并与页分裂

原文标题：InnoDB Page Merging and Page Splitting
原文链接： https://www.percona.com/blog/2017/04/10/innodb-page-merging-and-page-splitting/
作者：Marco Tusa
译者：2014BDuck
博客地址： https://blog.2014bduck.com/archives/260
翻译时间：2019-12-22
备注：因为 V 站限制注册满 1000 天才能发出来..只能贴个简介、总结和博客链接了

如果你找过世上任何一位 MySQL 顾问，问他对你的语句和 /或数据库设计的建议，我保证他会跟你讲主键设计的重要性。特别是在使用 InnoDB 引擎的情景，他们肯定会给你解释索引合并和页分裂这些。这两个方面与性能息息相关，你应该在任何设计索引（不止是主键索引）的时候都将他们考虑在内。

你可能觉得这些听起来挺莫名其妙，没准你也没错。这不是容易的事，特别是讲到关于内部实现的时候。通常你都不会需要处理这些事情，并且你也不想去着手他们。

但是有时候这些问题又是必须搞清楚的。如果有这种情况，那这篇文章正适合你。

我尝试用这篇文章将一些最不清晰、InnoDB 内部的操作解释清楚：索引页的创建、页合并和页分裂。

在 InnoDB 中，数据即索引（译注：索引组织数据）。你可能听过这种说法，但它具体是什么样的？

正文

MySQL/InnoDB 不断地进行这些操作，你可能只能了解到很少的信息。但他们可能给你造成伤害，特别是比起用 SSD，你还在用传统的机械存储（ spindle storage ）的时候（顺便提一下 SSD 会有另外的问题）。

坏消息就是我们用什么参数或者魔法去改变服务端。但好消息是我们可以在设计的时候做很多（有帮助）的事。

恰当地使用主键和设计辅助索引，并且记住不要滥用（索引）。如果你已经预计到会有很多插入 /删除 /更新操作，规划一个合适的时间窗来管理（整理）表。

有个很重要的点，InnoDB 中你不会有断断续续的行记录，但是你会在页-区的维度上遇到这些问题。忽略表的管理工作会导致需要在 IO 层面、内存层面和 InnoDB 缓冲池层面做更多工作。

你必须不时（ at regular intervals ）重建一些表。可以采用一些技巧，比如分区和外部的工具（ pt-osc ）。不要让表变得过大和过于碎片化（ fragmented ）。

磁盘空间浪费？需要读多个表去获取需要的数据而不是一次搞定？每次搜索导致明显更多的读操作？那是你的锅，不要找借口！

Happy MySQL to everyone!

Laurynas Biveinis: 感谢花时间向我解释一些内部实现。

Jeremy Cole: 感谢他的项目InnoDB_ruby (我经常用上）。