500+ 萬行表的主鍵列的選擇查詢沒有響應

Question

我在 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]

我不知道哪里可能出錯，為什么要花這么多時間。 請建議我一些解決方法或技術，因為這是一個關鍵表，主要報告嚴重依賴於該表。

Answer 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 。

參考：

1. 壞習慣 - 計算困難的方式
2. 快速計數 - Stackoverflow
3. 列存儲索引快速計數

Answer 2

當您在沒有where子句的情況下執行COUNT(Column) 、 COUNT(1) 、 COUNT(*)時會發生什么：

SQL Server 查找將完成這項工作的最小（包含最少的列數，單個 AK 頁中的最多行）索引。

如果您只有一個聚集索引，這意味着它將使用聚集索引。 （聚集索引包含表的所有列）

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

1. 創建一個只有 1 列的單獨索引，最好是小數據類型。 （創建索引可能需要很多時間）。
2. 為您的查詢創建索引視圖。 由於您不分組，因此我不建議這樣做。
3. 指定表提示WITH(TABLOCK)或WITH(TABLOCKX)以強制表鎖或排他表鎖。