问题标签 [fillfactor]

通常，当我在表上创建索引时，我通常Fill Factor会根据对如何使用表的有根据的猜测（多次读取或多次写入）来猜测应该是什么。

是否有更科学的方法来确定更准确的Fill Factor值？

在 MySql 中创建索引时如何指定填充因子？

我一直在网上搜索书籍和谷歌咒语，试图找出叶页中的物理填充因子（SQL Server 2000 和 2005）。

我知道它是创建索引时页面上剩余的可用空间量，但我没有发现该空间实际上是如何留下的：即，它是页面末尾的一大块，还是它通过该数据有几个差距。

例如，[只是为了简单起见]，假设一个页面只能容纳 100 行。如果填充因子被声明为 75%，这是否意味着页面的第一个（或最后一个）75% 是数据，其余部分是空闲的，或者每四行空闲一次（即页面看起来像：数据，数据，数据，免费，数据，数据，数据，免费，...）。

总而言之，我正在掌握在将行插入具有聚集索引的表时发生的物理操作的确切情况，并且插入没有发生在行的末尾. 如果在一个页面中留下多个间隙，则插入的影响最小（至少在页面拆分之前），因为可能需要移动以容纳插入的行数被最小化。如果间隙在表中的一大块中，那么处理行的开销（至少在理论上）会显着增加。

如果有人知道 MSDN 参考，请指点我！我现在找不到（虽然仍在寻找）。从我读过的内容来看，这暗示着它有很多差距——但这似乎并没有明确说明。

有没有办法在 SQL Server 2005/2008上找到有关表读取和写入计数的统计信息？

我专门寻找DMVs/DMFs不使用触发器或审计。

这里的目标是为索引找出合适的填充因子- 从这篇文章中得到一个想法（填充因子定义）。

[更新] ServerFault 上有一个后续问题
How to determine Read/Write intensive table from DMV/DMF statistics

我有一个非聚集索引，它有大约 1000 个页面、95% 的碎片和“0”的 FillFactor。

我在周日重建了索引。一周后，索引又出现了 95%（左右）的碎片。这是否表明我需要将 FillFactor 更改为 80-90%？

我是否应该每周调整填充因子以查看是否可以每周减少碎片？有我拍摄的目标水平吗？

谢谢你。

是否可以更改 PostgreSQL 8.4 中现有表的填充因子？

或者我是否必须使用新的填充因子创建表的副本——由于外键问题，这不是最好的方法？

是否有任何工作方法可以修改数据库中所有表的主键的填充因子参数？

是的，fillfactor再次。我花了很多时间阅读，我无法决定每种情况下什么是最好的。我不明白碎片何时以及如何发生。我正在将数据库从 MS SQL Server 迁移到 PostgreSQL 9.2。

情况1

在顺序（串行）PK 中 10-50 次插入/分钟，20-50 次读取/小时。

案例2

类似的结构，串行PK的索引，每2个月写入约50.000个寄存器的块（一次），读数10-50 /分钟。

50% 的填充因子是否意味着每次插入都会生成一个新页面并将 50% 的现有行移动到新生成的页面？

50% 的填充因子是否意味着在新数据页的物理行之间分配了释放空间？

仅当现有页面中没有可用空间时才会生成新页面？

如您所见，我很困惑；我会很感激一些帮助——也许是阅读 PostgreSQL 和 index 的好链接fillfactor。

我有一个带有 Binary(128) 列的表。我选择了 Binary(128) 而不是 Varbinary(128)，因此它会保留所有 128 个字节并在更新二进制值时防止页面拆分。出于测试目的，我的索引上的 FILLFACTOR 为 100。

我发现即使将列设置为 Binary(128) 值，在对该列执行更新时仍会导致页面拆分。

有人知道为什么吗？

这是一些要测试的代码...

如果您使用 100 的 FILLFACTOR 执行大型更新，则会导致严重的碎片，但如果我的 FILLFACTOR 为 90，一切都很好。我认为非 var 数据类型应该保留内存，所以你不会遇到这个问题。存储膨胀从何而来？

谢谢！

我必须将我的数据库导出到一个 bacpac 文件中才能将其导入 Azure。当我尝试导出时，我得到一个错误，因为任何索引都有一个 fillFactor 值。

我找到了如何为所有索引设置一个 fillFactor 值，但我不能指定 0，该值必须在 1 到 100 之间。如果我在管理工作室中更改该值，我可以将其设置为 0。

问题是我有很多索引要更改，我想通过 tsql 将 fillFactor 值更改为所有索引。

有任何想法吗？。

谢谢。