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