B 树的填充因子。为什么在右侧扩展索引而不是在其他情况下（创建索引期间除外）时会考虑填充因子？答案

【问题标题】：Fill factor For B-trees. Why fill factor is respected when extending the index at the right and not in other case (except during index creation)?B 树的填充因子。为什么在右侧扩展索引而不是在其他情况下（创建索引期间除外）时会考虑填充因子？
【发布时间】：2021-10-14 21:22:46
【问题描述】：

我正在尝试了解 btree 索引的填充因子。来自 postgres 文档：

对于 B 树，叶页在初始阶段填充到此百分比索引构建，以及在右侧扩展索引时（添加新的最大键值）。

首先，向右扩展索引是什么意思？这是否意味着分裂B树中最右边的叶子？（图片会很有帮助）。

为什么在这种情况下会考虑fillfactor，而只在创建索引时才考虑？

据我所知，postgresql 在创建过程中会考虑填充因子。例如，填充因子 = 50%，在创建索引后，叶子最多将填充 50%，然后，对于新的插入，此参数将不被考虑（预期此“右扩展”）。

【问题讨论】：

标签： postgresql fillfactor

【解决方案1】：

B-tree 索引的最右边的叶子页面是其中具有最大值的页面：

                        +---------+
                        |root page|
                        +---------+
                        /          \
                       /            \
           +----------+              +----------+
           |inner page|              |inner page|
           +----------+              +----------+
            /        \                 /       \
           /          \               /         \
+-----------+  +-----------+  +-------------+  +-------------+
|1 3 ... 100|  |101 ... 900|  |1000 ... 2000|  |2000 ... 5000|
+-----------+  +-----------+  +-------------+  +-------------+
  leaf page      leaf page       leaf page    rightmost leaf page

由于在最右边的页面中插入新值是一种常见情况，例如使用自动递增的序列值或不断增加的时间戳，因此对插入的处理方式不同，就像创建索引时一样。理由是此类插入通常是由INSERTs 而非UPDATEs 引起的。

如果最右边的页面被视为所有其他页面，那么自动递增的主键或时间序列通常会创建一个密集的索引，而不管fillfactor 设置如何。那么第一个不是HOT 的UPDATE 创建一个新的索引条目会导致索引页被拆分，这是很昂贵的。这将违背将fillfactor 设置为低于 100 以防止过多的页面拆分和碎片的概念。

INSERTs 无处不在，例如主键的 UUID，许多叶子页面将自动不会被完全填满。

【讨论】：