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

他们正在制作漂亮的(四舍五入的)数字。。。

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(4字节),sys.sysindexes中的indid的类型为smallint(2字节)(SQL Server 2008,可能比以前的版本有所增加)

我觉得这篇文章既有帮助又有趣 Tibor Karaszi. Key count in sys[.]indexes

不过,它们只是武断的限制,很少有人会在实践中遇到。大概他们需要设置一些最大限度,这样他们就知道在内部结构中分配多少空间。也许他们刚决定 decimal(3,0) 存储索引文件就足够了!

如果他们允许的话 1000 在SQL Server 2008中,您会问为什么不 1001 ?

嗯,对于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原因?

早期版本的SQLServer将使用TyyIn字段作为索引ID。Tinyint的最大值为255。设计团队可能已经将其舍入到250,以便于记忆(正如他们对varchar字段的8000个字符限制所做的那样)。250个索引被拆分:一个聚集索引和249个非聚集索引。

它基本上是一个内部实现限制。它不是由元数据大小(即tinyint列或索引id的小int列)驱动的,而是反映内部限制的元数据列。

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