对 500+ 百万行表的主键列的选择查询没有响应答案

【问题标题】：Select query on primary key column of 500+ million rows table is not responding对 500+ 百万行表的主键列的选择查询没有响应
【发布时间】：2020-12-22 07:41:48
【问题描述】：

我在 SQL Server 中有一个表，该表有 500+ 百万行，并在表的主键上定义了默认聚集索引。我正在运行这个需要 30 多分钟的简单查询。

Select count(ledgeridXXX) from Ledger.dbo.tblXXXX

这里是聚集索引定义的块

CONSTRAINT [PK__tblDepar__AE70E0AFF9BAF7B9] PRIMARY KEY CLUSTERED 
(
    [LedgerIDXXX] ASC
) 
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
      ALLOW_PAGE_LOCKS = ON
) ON [PRIMARY]

我不知道哪里可能出错，为什么要花这么多时间。请就如何修复它向我提出一些方法或技术，因为这是一个关键表，主要报告严重依赖此表。

【问题讨论】：

你试过count(*)吗？该列可以为空吗？
不，它是表的主键。我不想要 * 因为这会增加更多时间。
使用粘贴计划向我们展示估计的执行计划。
如果它不为空，那为什么会增加什么？
count(not_null_column) 比count(*) 快是一个从未有过的神话——两者的性能完全相同。所以count(*) 不会改变任何东西，我很确定 SQL Server 对两者使用完全相同的执行计划。我想您无能为力，除了在问题上投入更快的硬件，或者让 SQL Server 使用并行线程进行计数。但最后它必须遍历表中的所有行才能进行计数

标签： sql-server indexing query-performance large-data

【解决方案1】：

如果你只是计算行数，你可以试试这个：

SELECT SUM(p.rows) as [cnt]
FROM sys.partitions AS p
INNER JOIN sys.tables AS t ON p.[object_id] = t.[object_id]
INNER JOIN sys.schemas AS s ON t.[schema_id] = s.[schema_id]
WHERE p.index_id = 1 /* clustered index */
AND t.name = N'tblXXXX'AND s.name = N'dbo';

COUNT(clusteredkey) 可能会在您有大量工作负载时产生一些开销。扫描整个 5 亿行可能需要数小时。

如果你运行的是更高版本的SQL Server，你可以使用列存储索引来加速COUNT。

参考资料：

【讨论】：

试过这个，有一个 145M 行的表，很快。感谢您的精彩查询！
这只是一个伪查询，这个表是供不同需求的sp使用的
我提供了一些您可以使用的技术。您没有提到原始问题的任何 sp/other 要求。 “这张表被sp使用，有不同的要求sp和有什么不同的要求”是什么意思？

【解决方案2】：

当您在没有where 子句的情况下执行COUNT(Column)、COUNT(1)、COUNT(*) 时会发生什么：

SQL Server 会找到能够完成这项工作的最小（包含最少的列、单个 AK 页面中的最多行）的索引。

如果你只有一个聚集索引，这意味着它将使用聚集索引。（聚集索引包含表的所有列）

你可以做些什么来加快速度：

创建一个只有 1 列的单独索引，最好是小数据类型。（创建索引可能需要很长时间）。
为您的查询创建索引视图。由于您没有分组，我不建议这样做。
指定表提示WITH(TABLOCK) 或WITH(TABLOCKX) 以强制表锁或排他表锁。

【讨论】：