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

原文标题：InnoDB Page Merging and Page Splitting

作者：Marco Tusa

译者：2014BDuck

翻译时间：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 (我经常用上)。