3

当我在包含大约一亿行的表中查询特定日期的最小 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

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

4

4 回答 4

5

问题的根本原因是未对齐的非聚集索引，以及 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';

选择的计划

优化器利用索引（ordered on 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;

执行计划是：

系列计划

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

平行计划

于 2012-12-16T06:30:11.913 回答
1

尽管以不需要索引提示的方式解决问题可能是明智的，但快速的解决方案是：

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

这会强制进行表扫描。

或者，试试这个，尽管它可能会产生同样的问题：

select top 1 Id
from Connection
WHERE DateConnection = '2012-06-26'
order by Id
于 2012-07-26T21:46:31.733 回答
-1

找到最小值比浏览所有记录需要更长的时间，这是有道理的。找到未排序结构的最小值比遍历它一次需要更长的时间（未排序，因为 MIN() 没有利用标识列）。由于您使用的是标识列，因此您可以做的是有一个嵌套选择，您可以在其中从具有指定日期的记录集中获取第一条记录。

于 2012-07-25T08:29:31.933 回答
-2

NC 索引扫描在你的情况下是个问题。它使用唯一的非聚集索引扫描，然后对于每一亿行的行，它将遍历聚集索引，因此它会导致数百万的 io （通常说你的索引高度是 4那么它可能会导致 100,000,000*4 IO 的 +index 扫描非聚集索引叶页）。优化器必须选择这个索引以避免 strem 聚合得到最小值。要找到最小值有 3 种主要技术，一个是在我们想要 min 的列（如果有索引，这是有效的，在这种情况下，只要你得到它返回的行就不需要计算），第二个它可以使用散列聚合（但它通常发生在你有分组依据时）和第三个是流聚合在这里它将扫描所有合格的行并始终保持最小值并在扫描所有行时返回最小值..

然而，当没有 min 的查询使用聚集索引扫描时，它会很快，因为它必须读取更少的页面数，因此更少的 io。

现在的问题是为什么优化器会在非聚集索引上进行索引扫描。我确信这是为了避免流聚合中涉及的计算，以使用流聚合找到最小值，但在这种情况下，不使用流聚合的成本要高得多。这取决于估计，所以我猜表中的统计数据不是最新的。

所以首先检查你的统计数据是否是最新的。统计数据最后一次更新是什么时候？

因此要避免这个问题。请执行以下操作 1. 首先更新表统计信息，我相信它必须解决您的问题。2.如果你不能使用update stats或者update stats没有改变计划并且仍然使用NC索引扫描，那么你可以强制聚集索引扫描，以便它使用更少的IO，然后使用流聚合来获得最小值。

于 2012-07-26T20:33:55.933 回答