我有一个带有唯一聚集索引 myId 的表 myTable ，填充因子为 100% 它是一个整数，从零开始（但它不是表的标识列）我需要向表中添加一种新类型的行。如果我可以通过使用 myId 的负值来区分这些行，那可能会很好。
负值会导致额外的页面拆分并减慢插入速度吗？
额外背景：此表作为 etl 的一部分存在，用于从不同系统收集数据的数据仓库。我现在想容纳一种新型数据。我这样做的一种方法是为这些新数据保留负 ID，因此将自动聚类。这也将避免架构中的主要关键更改或额外列。
答案摘要： 100% 的填充系数通常会减慢插入速度。但不是顺序发生的插入，包括顺序否定插入。
不足以注意到任何合理的系统。
页面拆分发生在页面已满时，无论是在范围的开头还是结尾。只要你定期维护索引...
编辑，填充因子评论后：
在使用 90 或 100 FF 进行页面拆分后，每页将占满 50%。FF = 100 仅表示插入将更快发生（可能是第一次插入）。
对于严格单调递增（或递减）的键（+ve 或 -ve），页面拆分发生在范围的任一端。
但是，从 BOL，FILLFACTOR
填
将数据添加到表的末尾
如果新数据均匀分布在整个表中，则除 0 或 100 之外的非零填充因子可能对性能有好处。但是，如果将所有数据都添加到表的末尾，则不会填充索引页中的空白空间。例如，如果索引键列是 IDENTITY 列，则新行的键始终在增加，并且索引行在逻辑上添加到索引的末尾。如果将使用延长行大小的数据更新现有行，请使用小于 100 的填充因子。每页上的额外字节将有助于最大程度地减少由行中的额外长度引起的页面拆分。
那么，对于严格单调的键，填充因子是否重要......？特别是如果它是低容量写入
除了您已经获得的实际管理点和可疑使用负 id 来表示数据模型属性之外，这里还有一个有效的问题：给出一个 int id 从 0 到 N 的表，插入新的负值这些值会去哪里他们会导致额外的分裂吗？
初始行将放置在聚集索引叶页上，id 为 0 的行位于第一页，id 为 N 的行位于最后一页，填充中间的页面。当插入值为 -1 的第一行时，这将排在 id 为 0 的行之前，因此将向树中添加一个新页面（实际上将分配 8 个页面的范围，但这是不同的点）和将链接页面放在叶级链接列表前面的页面。这不会导致前第一页的页面拆分。在进一步插入值 -2、-3 等时，它们将转到同一个新页面，并且它们将被插入到正确的位置（-2 在 -1 之前，-3 在 -2 之前等），直到页面填满。进一步的插入将在此页面之前添加一个新页面，该页面将容纳更多的新值。插入正值 N+1，
所以基本上答案是这样的：在聚集索引的任一端插入都不应该导致页面拆分。页面拆分只能由两个现有键之间的插入引起。这实际上也扩展到非叶页面，集群两端的索引也可能不会拆分非叶页面。我当然不会在这里讨论更新的影响（如果增加可变长度列的长度，它们可能会导致拆分）。
最近在 SQL Server 博客圈中关于页面拆分的潜在性能问题的讨论很多，但我必须警告不要采取不必要的极端来避免它们。页面拆分是一种正常的索引操作。如果您发现自己处于插入期间页面拆分性能影响可见的环境中，那么“缓解”措施可能会给您带来更严重的打击，因为您将创建人为的页面闩锁热点，这些热点要糟糕得多影响每个插入。真实情况是，频繁拆分的长时间操作会导致高碎片化，从而影响数据访问时间。我说最好通过非高峰期定期索引维护操作（重组）来缓解这种情况。避免过早的优化，总是先测量。
一点都不。负值与正值一样有效。没问题。基本上，在内部，它们都只是 4 个字节的 0 和 1 :-)
马克
你问错问题了！
如果创建填充因子为 100% 的聚集索引，则每次插入、删除甚至修改记录时，都可能发生页面拆分，因为现有索引数据页面上可能没有空间来写入更改。
即使定期维护索引，100% 的填充因子在您知道将要执行插入的表上也会适得其反。更常见的值是 90%。
我担心这篇文章可能走错了方向，因为这里似乎存在一个潜在的设计问题，而不管产生的页面拆分如何。
为什么需要引入否定ID？
例如，整数主键应该唯一标识一行，它的符号应该是无关紧要的。如果不是这种情况，我怀疑您的表的主键可能存在定义问题。
如果您需要标记/识别新插入的记录，则专门为此目的创建一个列。
此解决方案将是理想的，因为您可以确保您的主键是顺序的（可能使用身份数据类型，尽管不是必需的），从而完全避免页面拆分问题（插入时）。
另外，为了确认是否可以，聚集索引主键（例如标识整数）的填充因子为 100%，不会导致顺序插入的页面拆分！