Sql Server中非聚集索引计数的原因答案

【问题标题】：Reason for the count of non clustered index in Sql ServerSql Server中非聚集索引计数的原因
【发布时间】：2011-05-13 19:19:06
【问题描述】：

为什么我们在 sql server 2005 中有 249 个非聚集索引？为什么不是 240 或 300？和 sql server 2008 的相同问题，为什么 999 ？为什么不是 800 或 1000？

【问题讨论】：

这个问题的兴趣是什么？
@iDevlop 因为我是 Sql Server 2005 的新手，我在阅读 Internet 上的教程时想到了这个问题。我始终相信 stackoverflow 是提出技术问题的最佳场所之一。可能我一辈子都不会在一张表上创建 249 个非聚集索引，但知道原因并没有什么坏处。因为作为一个学习者，我一直把这件事牢记在心，“没有什么是没有理由的”。一定有什么原因。
好吧，如果你把你的收入花在这里，那么在 SQL Server 2008 中将问题扩展到 999，因为有些答案可以通过 indid 的 tinyint 容量 (0-255) 来解释

标签： sql-server sql-server-2008 sql-server-2005 non-clustered-index

【解决方案1】：

AFAIK 它们只是任意限制，很少有人在实践中遇到过。大概他们需要设置一些最大限制，以便他们知道在其内部结构中分配多少空间。也许他们只是认为decimal(3,0) 足以存储 indexid！

如果他们在 SQL Server 2008 中允许使用 1000，那么您会问为什么不使用 1001？

【讨论】：

【解决方案2】：

早期版本的 SQL Server 会使用 tinyint 字段作为索引 ID。 Tinyint 的最大值为 255。设计团队可能已将其向下舍入为 250，以便于记忆（就像他们对 varchar 字段的 8000 个字符限制所做的那样）。 250 个索引被拆分：1 个聚集索引和 249 个非聚集索引。

【讨论】：

在 SQL Server 2005 中，堆的 indexid 为 0，聚集索引为 1，非聚集索引为 2-250，其余 id 保留供内部使用。

【解决方案3】：

嗯，对于 SQL Server 2005 及更早版本..

0 = 堆。每个表在 sys.indexes 中至少有一个条目，即使它没有索引
1 = 集群
255 = 用于 SQL Server 2000 和更早版本的 LOB 列（现在不记得为什么了）

因此，您立即拥有最多 253 个 NC 索引（2 到 254）。

四舍五入？还是一些旧版 SQL Server 7.0/6.5/6.0/4.2 的原因？

【讨论】：

【解决方案4】：

他们正在制作漂亮（四舍五入）的数字......

SQL Server 2005： 1 Clustered Index + 249 Nonclustered Indexes = 250 Indexes per table

SQL Server 2008： 1 Clustered Index + 999 Nonclustered Indexes = 1000 Indexes per table

更新：
您应该问为什么在 SQL Server 2008 中使用 999。
这已在回复my question 时进行了解释。 SQL Server 2008 中引入过滤索引解释了这种增加。

index_id in sysindexes means的数据类型：

0 表示堆
1 - 聚集索引
>1 个非集群
>=3200 - XML 索引

因此，我们仍然可以观察到在 SQL Server 的未来版本中增加到 3198(3199-1)。

我之前认为 sys.indexes 是 sysindexes 的同义词，但我现在发现它们不同，sysindexes 具有 indid（而不是 index_id）并且不包含 XML 索引的行！

来自 sys.indexes 的 index_id 的类型为 int(4bytes)，来自 sys.sysindexes 的 indid 的类型为 smallint (2bytes)（SQL Server 2008，可能比以前的版本有所增加）

我发现文章Tibor Karaszi. Key count in sys[.]indexes 很有帮助和有趣

【讨论】：

这很有帮助。所以我明白，如果我在表上创建了 1 个聚集索引，我现在只能创建 3199 - 1 = 3198 非聚集索引。之后，如果我们创建任何索引，它将属于 XML 索引。
那么sql server 2008中非聚集索引的实际限制是3198而不是999？
实际限制取决于我写的 SQL Server 版本。在 SQL Server 2008 R2 中是 999，在 2005 中是 249。如果超过它，编译器会报错。这很简单。我不认为2198也是极限。是否有必要，可以调整使用的数据类型和数字。这只是实施。不多也不少
感谢 vgv8。我得到了答案。

【解决方案5】：

这基本上是一个内部实现限制。它不是由元数据大小（即 index_id 的 tinyint 列或小的 int 列）驱动的，而是反映内部限制的元数据列。

每当出现这样的限制时，就意味着代码中的某处对于如何处理这种限制存在实际限制。举个例子，如果查询计划的生成必须考虑同一张表上的数万个索引，那么查询计划的生成可能会变得过于复杂，并且即使是一个微不足道的计划也会花费更多的时间。面对此类问题时，会在被视为“合理”的数字上划出一条线。在 90 年代后期，大约 250 个索引似乎是合理的，在 R2 中限制被推到了 1000。

【讨论】：