SQL Server - 加快大表的计数

Question

我有一张包含接近 3000 万 条记录的表格。只有几列。 'Born' 列之一的值不超过 30 个，并且上面定义了一个索引。我需要能够过滤该列并有效地翻阅结果。

现在我有（例如，如果我正在搜索的年份是“1970” - 它是我的存储过程中的一个参数）：

WITH PersonSubset as
(
    SELECT *, ROW_NUMBER() OVER (ORDER BY Born asc) AS Row
    FROM Person WITH (INDEX(IX_Person_Born)) 
    WHERE Born = '1970'
)
SELECT *, (SELECT count(*) FROM PersonSubset) AS TotalPeople
FROM PersonSubset
WHERE Row BETWEEN 0 AND 30

这种类型的每个查询（仅使用Born 参数）都会返回超过 100 万个结果。 我注意到最大的开销是用于返回总结果的计数。如果我从 select 子句中删除 (SELECT count(*) FROM PersonSubset) AS TotalPeople，整个过程会加快很多。

有没有办法加快该查询中的计数。我关心的是返回分页结果和总数。

Answer 1

更新了以下 cmets 中的讨论

这里问题的原因是IX_Person_Born索引的cardinality很低。

SQL 索引非常擅长快速缩小值范围，但是当您有大量具有相同值的记录时，它们就会出现问题。

你可以把它想象成电话簿的索引——如果你想找到“Smith, John”，你首先会发现有很多以 S 开头的名字，然后是一页又一页叫 Smith 的人，然后是很多约翰。你最终扫描了这本书。

这很复杂，因为电话簿中的索引是聚集的——记录是按姓氏排序的。相反，如果您想找到每个叫“约翰”的人，您需要进行大量查找。

这里有 3000 万条记录，但只有 30 个不同的值，这意味着最好的索引仍然返回大约 100 万条记录 - 在这种规模下，它还可能是表扫描。这 100 万个结果中的每一个都不是实际记录 - 它是从索引到表的查找（电话簿类比中的页码），这使得它变得更慢。

高基数指数（比如完整的出生日期）而不是年份会快得多。

这是所有 OLTP 关系数据库的普遍问题：low cardinality + huge datasets = slow queries，因为索引树没有多大帮助。

简而言之：使用 T-SQL 和索引获取计数没有明显更快的方法。

你有几个选择：

1。数据聚合

OLAP/Cube 汇总或自己做：

select Born, count(*) 
from Person 
group by Born

优点是多维数据集查找或检查缓存非常快。问题是数据会过时，您需要一些方法来解决这个问题。

2。并行查询

分成两个查询：

SELECT count(*) 
FROM Person 
WHERE Born = '1970'

SELECT TOP 30 *
FROM Person 
WHERE Born = '1970'

然后在并行服务器端运行这些，或将其添加到用户界面。

3。无 SQL

这个问题是 no-SQL 解决方案相对于传统关系数据库的一大优势。在无 SQL 系统中，Person 表在许多廉价服务器之间联合（或分片）。当用户搜索每个服务器时，同时检查。

此时，技术变革可能已经结束，但可能值得研究，因此我将其包括在内。

我过去在使用这种大小的数据库时也遇到过类似的问题，并且（取决于上下文）我使用了选项 1 和 2。如果这里的总数用于分页，那么我可能会选择选项2 和 AJAX 调用以获取计数。

Answer 2

DECLARE @TotalPeople int
  --does this query run fast enough?  If not, there is no hope for a combo query.
SET @TotalPeople = (SELECT count(*) FROM Person WHERE Born = '1970')


WITH PersonSubset as
(
    SELECT *, ROW_NUMBER() OVER (ORDER BY Born asc) AS Row
    FROM Person WITH (INDEX(IX_Person_Born)) 
    WHERE Born = '1970'
)
SELECT *, @TotalPeople as TotalPeople
FROM PersonSubset
WHERE Row BETWEEN 0 AND 30

您通常不能采用慢速查询，将其与快速查询结合起来，然后以快速查询结束。

---

“Born”列的其中一个具有不超过 30 个不同的值，并且在其上定义了一个索引。

SQL Server 没有使用索引或统计信息，或者索引和统计信息不够有用。

这是一个绝望的措施，它将迫使 Sql 采取行动（以使写入非常昂贵的潜在成本 - 衡量这一点，并阻止对 Person 表的架构更改，同时视图存在）。

CREATE VIEW dbo.BornCounts WITH SCHEMABINDING
AS
SELECT Born, COUNT_BIG(*) as NumRows
FROM dbo.Person
GROUP BY Born

GO 

CREATE UNIQUE CLUSTERED INDEX BornCountsIndex ON BornCounts(Born)

通过在视图上放置聚集索引，您可以使其成为系统维护的副本。此副本的大小远小于 3000 万行，并且包含您要查找的确切信息。我不必更改查询以使其使用视图，但如果您愿意，您可以在查询中随意使用视图的名称。

Answer 3

WITH PersonSubset as
(
    SELECT *, ROW_NUMBER() OVER (ORDER BY Born asc) AS Row
    FROM Person WITH (INDEX(IX_Person_Born)) 
    WHERE Born = '1970'
)
SELECT *, **max(Row) AS TotalPeople**
FROM PersonSubset
WHERE Row BETWEEN 0 AND 30

为什么不这样呢？

编辑，不知道为什么粗体不起作用：

Answer 4

这是一种使用系统 dmv 的新颖方法，如果您可以通过“足够好”的计数，您不介意为 [Born] 的每个不同值创建一个索引，并且您不介意有一点感觉里面有点脏。

为每一年创建一个过滤索引：

--pick a column to index, it doesn't matter which.    
CREATE INDEX IX_Person_filt_1970 on Person ( id )  WHERE Born = '1970'
CREATE INDEX IX_Person_filt_1971 on Person ( id )  WHERE Born = '1971'
CREATE INDEX IX_Person_filt_1972 on Person ( id )  WHERE Born = '1972'

然后使用 sys.partitions 中的 [rows] 列来获取行数。

WITH PersonSubset as
(
    SELECT *, ROW_NUMBER() OVER (ORDER BY Born asc) AS Row
    FROM Person WITH (INDEX(IX_Person_Born)) 
    WHERE Born = '1970'
)
SELECT *, 
    (
    SELECT sum(rows) 
    FROM sys.partitions p 
        inner join sys.indexes i on p.object_id = i.object_id and p.index_id =i.index_id 
        inner join sys.tables t on t.object_id = i.object_id 
    WHERE t.name ='Person' 
        and i.name = 'IX_Person_filt_' + '1970' --or at @p1 
    )  AS TotalPeople
FROM PersonSubset
WHERE Row BETWEEN 0 AND 30

Sys.partitions 不能保证在 100% 的情况下是准确的（通常是准确的或非常接近的）如果您需要过滤除 [Born] 之外的任何内容，此方法将不起作用