如何加速涉及count的SQL Server查询（distinct（））

Question

我有一个看似简单的SQL Server查询，比我预期的要花费更长的时间。

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT COUNT(DISTINCT(guid)) FROM listens WHERE url='http://www.sample.com/'

'guid'是varchar（64）NULL

'url'是varchar（900）NULL

guid和url有一个索引。

'listens'表中有超过700万行，其中17,000行与相关网址相匹配，查询结果为5,500。

在一台相当空闲的双核AMD Opteron 2GHz和1GB RAM上，在SQL Server 2008上运行此查询需要1分钟以上。

有关如何缩短执行时间的任何想法？ 理想情况下它应该在1秒以内！

Answer 1

在url上创建一个覆盖GUID的索引：

CREATE INDEX ix_listens_url__guid ON listens (url) INCLUDE (guid)

在将url作为标识符处理时，最好存储和索引URL哈希而不是整个URL 。

Answer 2

扫描索引，无论如何都需要很长时间。
你需要做的是缩短索引。
你可以做的是有一个整数列，其中计算和存储网址的校验和。 这样你的指数就会变窄，计数也会很快。

请注意，校验和不是唯一的，但它足够独特。 这是一个完整的代码示例，说明如何执行此操作。 我已经包含了两列的校验和，但它可能只需要一个。 您还可以自行计算插入或更新的校验和，并删除触发器。

CREATE TABLE MyTable
(
    ID INT IDENTITY(1,1) PRIMARY KEY,
    [Guid] varchar(64),
    Url varchar(900),
    GuidChecksum int,
    UrlChecksum int
)
GO

CREATE TRIGGER trgMyTableCheckSumCalculation ON MyTable
FOR UPDATE, INSERT
as
UPDATE t1
SET    GuidChecksum = checksum(I.[Guid]),
       UrlChecksum = checksum(I.Url)
FROM   MyTable t1 
       join inserted I on t1.ID = I.ID

GO
CREATE NONCLUSTERED INDEX NCI_MyTable_GuidChecksum ON MyTable(GuidChecksum)
CREATE NONCLUSTERED INDEX NCI_MyTable_UrlChecksum ON MyTable(UrlChecksum)

INSERT INTO MyTable([Guid], Url)
select NEWID(), 'my url 1' union all
select NEWID(), 'my url 2' union all
select null, 'my url 3' union all
select null, 'my url 4'

SELECT  *
FROM    MyTable

SELECT  COUNT(GuidChecksum)
FROM    MyTable
WHERE   Url = 'my url 3'
GO

DROP TABLE MyTable

Answer 3

我知道这篇文章有点晚了。 我正在寻找另一个优化问题。

注意到：

1. guid是VARCHAR（64）**而不是真正的16byte uniqueidentifier
2. url是varchar（900），你有700万行。

我的建议：

1. 为表创建一个新字段。 Column = URLHash AS UNIQUEIDENTIFIER创建新记录。 URLHash = CONVERT( UNIQUEIDENTIFIER, HASHBYTES('MD5', url) )
2. 在URLHash上构建索引

然后在你的查询中： SELECT COUNT(DISTINCT(guid)) FROM listens WHERE URLHash = CONVERT( UNIQUEIDENTIFIER, HASHBYTES( 'MD5', 'http://www.sample.com/' ) )

这将为您提供一种非常快速的方法来唯一地搜索特定的URL，同时保持非常小的索引大小。

如果您需要进一步优化，您可能希望在guid上执行相同的哈希。 在16byte uniqueidentifier上执行distinct更快比varchar（64）更快。

---

上面的假设是你没有在监听表中添加大量新行; 也就是说，新的记录率并不那么重。 原因是MD5算法虽然提供了完美的色散; 是出了名的慢。 如果要以每秒数千的速度添加新记录; 然后在创建记录时计算MD5哈希会降低服务器的速度（除非你有一个非常快的服务器）。 另一种方法是实现您自己的FNV1a散列算法版本，该算法不是内置的。 与MD5相比，FNV1a快得多，但提供了非常好的色散/低截留率。

希望以上可以帮助将来遇到这些问题的人。

Answer 4

从本质GUID ，你的GUID列将比一个bigint更耗费人力，因为它占用更多空间（ 16字节 ）。 是否可以使用自动递增的数字列替换GUID列，或者如果失败，则引入一个bigint / int类型的新列，该GUID列的每个新值递增（然后您可以使用GUID来确保全局唯一性，和bigint/in t用于索引目的）？

从上面的链接：

在16字节处，与其他数据类型（例如4字节整数）相比，uniqueidentifier数据类型相对较大。 这意味着使用uniqueidentifier键构建的索引可能比使用int键实现索引要慢。

你有没有特别的理由为你的guid列而不是uniqueidentifier使用varchar ？

Answer 5

一些提示......

1）重构您的查询，如使用with第...

with url_entries as (  
      select guid   
      from listens   
      where url='http://www.sample.com/'  
    )   
    select count(distinct(enries.guid)) as distinct_guid_count   
    from url_entries entries

2）告诉确切的SQL Serever在执行查询时必须扫描哪个索引（当然，按url字段索引）。 另一种方法 - 由guid简单的drop drop和仅由url leave index。 请在此处查看有关提示的更多信息。 特别是对于像select ... from listens with (index(index_name_for_url_field) )这样的构造select ... from listens with (index(index_name_for_url_field) )

3）验证listens表上的索引状态并更新索引统计信息 。

Answer 6

我敢打赌，如果你的机器内存超过1GB，它的性能会更好（我所遇到的所有DBA在生产SQL服务器中都至少需要4GB）。

我不知道这是否重要，但如果你做了

  SELECT DISTINCT(guid) FROM listens WHERE url='http://www.sample.com/'

@rowcount不会包含你想要的结果吗？

Answer 7

您最好的计划是获取17k候选URL的范围，并且计数不同于依赖于保证的输入顺序，因此它不必排序。 能够满足这两个要求的正确数据结构是(url, guid)上的索引：

CREATE INDEX idxListensURLGuid on listens(url, guid);

您已经获得了关于所使用密钥的广泛性的大量反馈，您可以定义寻求改进它们，并且如果可以的话，还可以增加1Gb的RAM。

如果可以在SQL 2008 EE上进行部署，那么请确保为这种高度重复且宽泛的索引打开页面压缩 。 由于降低了IO，它将在性能上创造奇迹。