我有一个大的表，它有一个带有标识主键的聚集索引。 我正在决定这个表的填充因子的正确值，以尽量减less页面拆分。 我们使用脚本每日运行测量碎片并采取适当的行动来维护索引。 该表包含可变长度的列。
我的第一个想法是把它设置为100（因为logging应该只写在表的末尾），但是我认为对可变长度列的更改也会导致页面拆分，所以现在我正在向90度转移。
任何意见赞赏。
这取决于
这是一个平衡的行为。 如果你的表是读密集的，没有太多的更新或删除，那么默认值（即100）应该是可以的。
如果你的表是非常写密集的，有大量的更新，那么低于80的值可能更合适。
这个东西没有神奇的公式。 （AFAIK，如果有请让我知道）最好的事情是有一个testing环境，有一定的工作量来testing。 进行更改并查看数据库如何执行工作负载。
Nick非常正确。
如果你做的更新增加了打包页面上的logging大小，那么你将会导致页面拆分，但除此之外，使用一个标识主键什么都不会导致聚簇索引中的页面拆分。
（虽然说存储引擎可以执行5种types的页面拆分，但并不是所有这些都会导致碎片和数据移动 – 插入monatonically增加的身份值时得到的是页面拆分。我离题了…）
我已经帮助了许多客户，而且我写了关于BOL的所有内容 – 如果你只想select一个价值作为实际利益，70％的人看到了最成功的一面。 正如尼克所说，适当地监控和调整。
为任何索引select填充因子是多less活动发生的平衡操作，将页面填满度推向100％，以及多久可以采取纠正措施来重置填充因子。 你需要考虑如果设置填充因子非常低，比如50％，那么在页面上最初会浪费多less空间，但是在某些情况下，我再次看到这是合适的。
你也应该考虑如何使用索引。 如果只是单身查找，你可能会得到一个较低的填充因子和更多的时间之间的重build/碎片整理，因为你不会浪费太多的IO /内存有很多稀疏的聚集索引在内存中。 为了进行大范围的扫描，你需要使fillfactor高一些，以提高IO和内存的效率。
还有OLTP和DW的问题 – 通常DW是不变的，所以索引将有100％的填充因子。 OLTP是最难的部分。
在对聚集索引进行分类之后，请记住，非聚类也需要关注，因为它们很可能会被分割。
重置填充因子时，请记住在重build和整理之间有一个select。 DBCC INDEXDEFRAG / ALTER INDEX …在某些情况下，REORGANIZE可以重新设置填充因子，用于没有严重碎片的索引。
希望这可以帮助！
（对不起，我的热键之一，写了代码:-)