Sql 如果地址空间连续，查找标识列是否更快？

如果我有一个非常大的表，表中有

标识
列（
bigint
），并且该表可能会被删除，那么地址空间（可用ID）的碎片会导致
选择的速度变慢吗


澄清：

“地址空间碎片”是指ID列中的值留下的间隙，而不是从表中删除行时磁盘上出现的碎片。
这取决于表的索引方式。假设您还在列上放置聚集索引，则使用该列的任何select语句都应该非常快。在极端情况下，如果你正在进行范围扫描，可能需要将一些额外的页面拉入内存，但在ID上这样做是非常罕见的。通常情况下，这些行是通过搜索得到的

您仍然应该有一个清理任何碎片的维护计划，特别是在您进行大量删除的情况下。但我必须承认，这不是我的强项，因此我不知道SQL 2008和/或您的存储介质是否会使这变得不必要。
显然，如果不运行测试，就无法确定这一点。然而，我会推测，如果它是连续的或是零碎的，它不会运行得更快或更慢

假设列已编制索引，SQL Server将索引存储在b树中。此树的节点被设计为系统寻呼系统的最佳大小。节点内的搜索将识别正确的子节点页，而不考虑索引的碎片。由于加载页面所需的时间将超过在节点内搜索所需的时间，我认为碎片化不会对查找时间产生任何影响

另一方面，如果列没有索引，那么SQL Server无论如何都必须执行完整的表扫描，因此值的分布根本不会影响时间

它可能会对查询计划优化产生影响。SQL Server存储列内容的柱状图，以便选择能够提供足够性能的查询计划。在我看来，碎片化可能会导致它选择一个不如它可能考虑的另一个计划好的计划。如果列统计信息不是最新的，则会出现这种情况。如果统计信息是最新的，那么将检测到碎片，优化器可以考虑这些信息。
否

如果它不是一个索引列，当然碎片并不重要，因为无论如何引擎都会扫描表。（根据实际的查询/连接，引擎不一定要进行表扫描，但从列本身的角度来看，引擎除了进行表扫描之外没有其他更好的事情可做）

如果是索引列，则索引存储在树结构中，在数据插入或删除过程中，该树结构会展开或收缩。对于这种树结构，您需要知道的一点是，即使按顺序插入数据，它也是“碎片化”的。这里的碎片不是磁盘分配单元的意思，但是树中的每个节点并没有完全用于它所覆盖的数据范围。目的是为了避免过于频繁的树重组。引擎在重构索引树时使用占用率（可在创建索引时指定）。因此，无论id是否连续，它都存储在一个更大的存储空间中，其中有一些“间隙”。删除该列不应在性能上产生任何明显差异

然而，数据库也会按页分配存储空间，这意味着会出现碎片和相关的性能问题。但对于您的问题，这与id列上的删除无关。
清除碎片，是指查找打开的id并更新使用中的最高id以及引用此id的所有FK？不，我的意思是确保清除所有磁盘碎片。ID中的漏洞应该不会对性能产生任何影响。好吧，这是我真正的问题，地址空间碎片，而不是磁盘碎片。谢谢