查询SQL Server中的最小值比查询所有行要长很多

Question

当我查询表中包含大约一亿行的特定日期的最小ID时,我目前在数据库中遇到了一种奇怪的行为.查询非常简单:

SELECT MIN(Id) FROM Connection WITH(NOLOCK) WHERE DateConnection = '2012-06-26'

这个查询结束了,至少我让它运行了几个小时.DateConnection列不是既不包含在其中的索引.所以我理解这个查询可以持续很长时间.但我尝试了以下几秒钟运行的查询:

SELECT Id FROM Connection WITH(NOLOCK) WHERE DateConnection = '2012-06-26'

它返回300k行.

我的表定义如下:

CREATE TABLE [dbo].[Connection](  
    [Id] [bigint] IDENTITY(1,1) NOT NULL,  
    [DateConnection] [datetime] NOT NULL,  
    [TimeConnection] [time](7) NOT NULL,  
    [Hour]  AS (datepart(hour,[TimeConnection])) PERSISTED NOT NULL,  
    CONSTRAINT [PK_Connection] PRIMARY KEY CLUSTERED   
    (  
        [Hour] ASC,  
        [Id] ASC  
    )  
)

它有以下索引:

CREATE UNIQUE NONCLUSTERED INDEX [IX_Connection_Id] ON [dbo].[Connection]  
(  
    [Id] ASC  
)ON [PRIMARY]

我发现使用这种奇怪行为的一个解决方案是使用以下代码.但对于这样一个简单的查询,我觉得相当沉重.

create table #TempId
(
    [Id] bigint
)
go

insert into #TempId
select id from partitionned_connection with(nolock) where dateconnection = '2012-06-26'

declare @displayId bigint
select @displayId = min(Id) from #CoIdTest

print @displayId 
go

drop table #TempId
go

有没有人遇到过这种行为,原因是什么？最小聚合扫描整个表吗？如果是这种情况,为什么简单选择不？

Answer 1

问题的根本原因是未对齐的非聚集索引,以及Martin Smith 指出的统计限制(详见另一个问题的答案).

您的表按以下方式分区[Hour]:

CREATE PARTITION FUNCTION PF (integer)
AS RANGE RIGHT
FOR VALUES (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23);

CREATE PARTITION SCHEME PS
AS PARTITION PF ALL TO ([PRIMARY]);

-- Partitioned
CREATE TABLE dbo.Connection
(
    Id              bigint IDENTITY(1,1) NOT NULL,
    DateConnection  datetime NOT NULL,
    TimeConnection  time(7) NOT NULL,
    [Hour]  AS (DATEPART(HOUR, TimeConnection)) PERSISTED NOT NULL,

    CONSTRAINT [PK_Connection]
    PRIMARY KEY CLUSTERED
    (  
        [Hour] ASC,  
        [Id] ASC  
    )
    ON PS ([Hour])
);

-- Not partitioned
CREATE UNIQUE NONCLUSTERED INDEX [IX_Connection_Id]
ON dbo.Connection
(  
    Id ASC
)ON [PRIMARY];

-- Pretend there are lots of rows
UPDATE STATISTICS dbo.Connection WITH ROWCOUNT = 200000000, PAGECOUNT = 4000000;

查询和执行计划是:

SELECT 
    MinID = MIN(c.Id)
FROM dbo.Connection AS c WITH (READUNCOMMITTED) 
WHERE
    c.DateConnection = '2012-06-26';

优化器利用索引(有序Id)将MIN聚合转换为TOP (1)- 因为根据定义,最小值将是有序流中遇到的第一个值.(如果非聚集索引也已分区,优化程序将不会选择此策略,因为所需的排序将丢失).

稍微复杂的是我们还需要在WHERE子句中应用谓词,这需要查找基表来获取DateConnection值.Martin提到的统计限制解释了为什么优化器估计它只需要检查有序索引中的119行,然后找到一个DateConnection值与之匹配的值WHERE clause.隐含的DateConnection和Id值之间的相关性意味着这个估计还有很长的路要走.

如果您感兴趣,Compute Scalar会计算执行Key Lookup的分区.对于非聚簇索引中的每一行,它计算一个类似的表达式[PtnId1000] = Scalar Operator(RangePartitionNew([dbo].[Connection].[Hour] as [c].[Hour],(1),(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12),(13),(14),(15),(16),(17),(18),(19),(20),(21),(22),(23))),并将其用作查找搜索的前导键.嵌套循环连接上有预取(预读),但这需要是一个有序的预取,以保留TOP (1)优化所需的排序.

解

我们可以通过找到Id每个Hour值的最小值,然后采用每小时最小值的最小值来避免统计限制(不使用查询提示):

-- Global minimum
SELECT 
    MinID = MIN(PerHour.MinId)
FROM 
(
    -- Local minimums (for each distinct hour value)
    SELECT 
        MinID = MIN(c.Id)
    FROM dbo.Connection AS c WITH(READUNCOMMITTED) 
    WHERE
        c.DateConnection = '2012-06-26' 
    GROUP BY
        c.[Hour]
) AS PerHour;

执行计划是:

如果启用了并行性,您将看到更像下面的计划,它使用并行索引扫描和多线程流聚合来更快地生成结果: