标签: fill-factor

假设您有一个默认填充因子为 20 的数据库。每当插入数据时，它是否只创建填充到 20% 的页面？

据我了解，插入数据时，页面中将有大约 20% 的数据。但是，当数据更新时，它会扩展到索引的 20% 以上，直到填充它并生成页面拆分，对吗？

我已经大量更新/访问了存储序列化 java 对象的表。它们在表中停留 2-3 小时（在此期间也在更新），然后被删除。表的大小约为 300MB。我发现它非常非常频繁地被 VACUUMed 并想知道改变它fillfactor是否会有所帮助？

你怎么知道一个索引应该有多少“填充”？

我了解填充因子、页面和索引结构，因此我理解为什么 100% 填充因子是一种罕见的最佳实践。那么为什么它默认为 0 （或 100% ）呢？为什么不是 90 或 95？

有什么我想念的吗？

所以我在 SQL Server 中的 ID 列（这是一个自动增量列）上有一个带有聚集索引的表。

是否可以将填充因子设为 100，因为数据将始终使用下一个最新 ID 写入？如果此表中的其他列针对现有 ID 进行大量更新，这是否重要？

此外，删除将如何影响表的碎片？

我对 MS SQL 中的页面拆分有点困惑，我正在寻找明确的答案。这个故事似乎有两个版本：

1 - Fillfactor 仅影响创建/重建索引时的完整页面。页面拆分始终为 50/50

2 - Fillfactor 也会影响页面的分割方式。因此，如果有 70% 的填充因子并且页面溢出，它将拆分 70/30

非常感谢

PostgreSQL 文档说，选择较小的fillfactor表可以为同一页面上的未来更新保留空间，并且

“这让 UPDATE 有机会将行的更新副本与原始行放在同一页上，这比将其放在不同的页上效率更高。”

事实上，如果集群存储在常规 HDD 驱动器上，这可以提高 UPDATE 性能，但我的是在 SSD 上。据我所知，设置fillfactor < 100不会给我任何性能优势，只会浪费（相对）昂贵的存储空间。

你对我的案子有反例吗？

昨晚将我们的数据库从 9.3.5 升级到 9.4.1 后，服务器遇到了高 CPU 峰值。升级是通过 pg_dump 完成的。于是把数据库转成SQL，再导入9.4。

在 CPU 峰值期间，日志中有很多这样的消息：

process X still waiting for ExclusiveLock on extension of relation Y of database Z 
after 1036.234 ms

和：

process X acquired ExclusiveLock on extension of relation Y of database Z
after 2788.050 ms

看起来可疑的是，有时在完全相同的毫秒内有几个完全相同的关系号的“获取”消息。

为什么 Postgres 会在同一毫秒内将一个表增长两次？它可能是一个具有高填充因子的索引吗？

欢迎任何有关如何解决此问题的建议。

PS 我也在Postgres 邮件列表上问过这个问题，如果不行，请告诉我。

我一直在四处挖掘，但没有任何运气。

SQL Server 2008：是否可以在不重建整个表的情况下调整特定聚集索引/表的填充因子？

例如，如果它有 4 亿条记录，我们是否可以调整填充因子并让 SQL Server 在所有尚未超过该限制的页面（以及新拆分）上使用新的填充因子，然后调整已超出该限制的页面？索引维护期间超限？

是否可以预先定义在下一次索引维护期间应该构建索引的填充因子？

我们一直遇到一个表上的页面拆分问题，这是一个特别麻烦的问题 - 它是数据库中活动的审计日志，并且已经增长到 1TB 以上。主要索引位于记录类型上，它是 an NVARCHAR(100)- 因为当有 5 种记录类型时您需要它 - 它比 aTINYINT和记录 id更有意义- 它是 anNVARCHAR(200)而不是记录的整数键。

它们还涵盖索引，包括键、旧值、新值等——非常广泛。

这是一个旧系统，不幸的是，这种审计的代码无处不在，而不是集中在一个程序中。它无法改变，我们正在经历漫长的微服务重写的痛苦过程。

因此，我将两个索引的填充因子从 100% 降低到 85%。

并且页面拆分变得更糟。我会说大约 3 倍的页面拆分。

这是一个普遍的结果吗？大多数建议说减少填充因子以提高页面拆分性能。我可以理解为什么它会这样做，因为键中数据的宽度。

建议是进一步降低填充因子，还是将其恢复原状？