在 Sql server 中创建非聚集索引的最小行数答案

【问题标题】：Minimum row count to create Non-clustered index in Sql server在 Sql server 中创建非聚集索引的最小行数
【发布时间】：2016-03-19 15:08:08
【问题描述】：

只是想知道，数据库中应该存在的最小记录数是多少，这样非聚集索引才能在简单的 SQL 查询中发挥优势。

我有一个包含 100K 记录的表，我的查询很简单，如下所示。

SELECT
   a,
   b,
   c,
   d
FROM
   Table
WHERE 
   d in ('@d')

我的表一天只更新一次。那么在“d”列上创建非聚集索引是否受益？

【问题讨论】：

你有桌子。你有数据。您可以应用该指数并衡量其效果。我们不能。
你有空间添加索引吗？如果这不是问题，您可能应该添加它，然后让查询优化器确定使用它是否明智。但正如达米安所说，这对你来说更像是一个问题，而不是我们。我们只是没有足够的信息（数据基数等）来说明什么是有益的。

【解决方案1】：

根据您对表的描述，您将在表上添加一个“堆”索引。这是一个表上的非聚集索引，其中没有聚集索引。

对于超过 100,000 行的表，这通常会降低查询的性能，但是，如果不仔细查看执行计划并且没有发布 DDL，这几乎只是猜测。

想要加快查询速度？考虑将聚集索引添加到表中，然后将非聚集索引添加到您正在搜索的列。如果表每天更新一次，我也会定期跟踪索引统计信息和碎片。如果这成为问题，您可以随时重建索引以获得最大效率。

正如我所说，猜测可行，但不要将非聚集索引添加到大表中。它仍然会进行表扫描，只是速度较慢。 Read more here.

【讨论】：

您是否对堆上超过一定大小的非聚集索引会降低性能的说法进行独立验证？我发现很难说服表扫描比索引查找或扫描后跟 RID 查找更有效。但我愿意今天学习一些东西。
所描述的表是教科书“不要使用堆表”的场景。如果您像我说的那样跟踪碎片，那么每天在聚集索引表上插入/更新一次就可以了。虽然查询具有这么多行的堆肯定会变慢，因为它没有以任何方式排序。将该表保持为堆意味着您每次都在对该表进行全面扫描，而聚簇表则不会。但是正如我所说的那样，差异可能很小，因为我看不到任何 DDL，也无法访问他的环境。你以为这是基本的数据库设计吗？
您的意思是，堆上的非聚集索引不能用于有效定位匹配行。如果是这样，为什么 SQL Server 允许您创建所述索引？如果它永远无法使用，那么创建索引时不应该出现“存储引擎无法使用此索引”的巨大错误吗？另外，我的环境中有几个堆有非聚集索引，它们被使用了。
另外，“认为这是基本的”并不是保持对话建设性的好方法。
我看不到我在“拉”什么？这是基本的数据库设计。在SELECT 查询密集型表上，聚集索引始终是最佳途径。这怎么能不明白呢？