Question

我现在有四个查询类型，试图从一个非常大的表中选择一个计数。

查询本质上就是这个。

SELECT count(PrimaryKeyIntColumn) from dbo.TableName

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn >= 0

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn IS NOT NULL

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn BETWEEN 1 and 2147483647

当我显示估计的执行计划时，我看到第一个是NonClustered Index Scan，第二个是Clustered Index Seek，第三个是NonClustered Index Scan，第四个是Clustered Index Seek。这或多或少是预期的（不是null通常是SARGable，除非主键已经不可为空，因此查询优化器可能只是抛出它）

问题是这些查询中的每一个相对于4个批次占用了25％的查询成本，每个查询的索引扫描或索引搜索占用了95％的成本。基本上，据我所知，在这个特定情况下，索引扫描和索引搜索之间没有真正的性能差异，即使应该存在。

确切的执行计划是SELECT 0％ - ＆gt;计算标量0％ - ＆gt;流聚合5％ - ＆gt;指数（扫描|寻求）95％

我不确定问题是什么，但搜索似乎没有扫描速度快一点。在我不耐烦之前运行每个旋转几分钟并取消查询。

虽然我知道我可以通过其他方式获得计数，但这并不是最终目标。我试图降低其他一些查询的性能，我不确定为什么将扫描转换为搜索没有做任何事情。我想如果我能找出为什么会发生这种情况，我或许可以找到问题的实际根源。

任何帮助将不胜感激。这是一个非常大的表，有超过1亿行数据。

这里有一个类似的问题：Poor clustered index seek performance?但它似乎并不适用于我。

Answer 1

这不是真正的追求。你只是寻求开始 - 并从那里进行范围扫描。由于您的范围（几乎）与整个表格完全相同，因此没有真正的区别。计数必须经过100M记录，无论是聚簇索引还是非聚簇索引。你不能指望它会很快。不，表格中没有存储rowcount您可以轻松阅读。

SQL Server索引扫描和索引搜索具有相同的性能

1 个答案: