使用TOP和ESCAPE更改查询计划和执行时间

Question

其中一个查询(如下所示)需要90秒以上才能执行.它从一个相当大的表LogMessage返回~500行.如果ESCAPE N'~'从查询中删除它,它会在几秒钟内执行.同样,如果TOP (1000)删除它,它会在几秒钟内执行.查询计划Key Lookup (Clustered) PK_LogMessage, Index Scan (NonClustered) IX_LogMessage and Nested Loops (Inner Join)在第一种情况下显示.当从句ESCAPE N'~'或TOP (1000)移除查询计划的变化,以及Clustered Index Scan (Clustered) PK_LogMessage.虽然我们正在寻找添加更多索引(可能在ApplicationName上),但我们想了解当前的情况.

正在生成查询Entity Framework,以防您想知道为什么以这种方式编写.实际查询也更复杂,但这是表现出相同行为的最短版本.

查询:

SELECT TOP (1000) 
    [Project1].[MessageID] AS [MessageID], 
    [Project1].[TimeGenerated] AS [TimeGenerated], 
    [Project1].[SystemName] AS [SystemName], 
    [Project1].[ApplicationName] AS [ApplicationName]
FROM
    (
        SELECT
            [Project1].[MessageID] AS [MessageID],
            [Project1].[TimeGenerated] AS [TimeGenerated],
            [Project1].[SystemName] AS [SystemName],
            [Project1].[ApplicationName] AS [ApplicationName]
        FROM
        (
            SELECT 
                [Extent1].[MessageID] AS [MessageID], 
                [Extent1].[TimeGenerated] AS [TimeGenerated], 
                [Extent1].[SystemName] AS [SystemName], 
                [Extent1].[ApplicationName] AS [ApplicationName]
            FROM
                [dbo].[LogMessage] AS [Extent1]
            INNER JOIN
                [dbo].[LogMessageCategory] AS [Extent2]
            ON
                [Extent1].[CategoryID] = [Extent2].[CategoryID]
            WHERE
                ([Extent1].[ApplicationName] LIKE N'%tier%' ESCAPE N'~')
        )  AS [Project1]
    )  AS [Project1]
ORDER BY
    [Project1].[TimeGenerated] DESC

表LogMessage:

CREATE TABLE [dbo].[LogMessage](
    [MessageID] [int] IDENTITY(1000001,1) NOT NULL,
    [TimeGenerated] [datetime] NOT NULL,
    [SystemName] [nvarchar](256) NOT NULL,
    [ApplicationName] [nvarchar](512) NOT NULL,
        [CategoryID] [int] NOT NULL,
 CONSTRAINT [PK_LogMessage] PRIMARY KEY CLUSTERED 
(
    [MessageID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,
    ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

ALTER TABLE [dbo].[LogMessage]  WITH CHECK ADD CONSTRAINT [FK_LogMessage_LogMessageCategory] FOREIGN KEY([CategoryID])
    REFERENCES [dbo].[LogMessageCategory] ([CategoryID])

ALTER TABLE [dbo].[LogMessage] CHECK CONSTRAINT [FK_LogMessage_LogMessageCategory]

ALTER TABLE [dbo].[LogMessage] ADD  DEFAULT ((100)) FOR [CategoryID]

CREATE NONCLUSTERED INDEX [IX_LogMessage] ON [dbo].[LogMessage] 
(
    [TimeGenerated] DESC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF,
    IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON,
    ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]

表LogMessageCategory:

CREATE TABLE [dbo].[LogMessageCategory](
    [CategoryID] [int] NOT NULL,
    [Name] [nvarchar](128) NOT NULL,
    [Description] [nvarchar](256) NULL,
 CONSTRAINT [PK_LogMessageCategory] PRIMARY KEY CLUSTERED 
(
    [CategoryID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

查询计划1(需要90多秒)

查询计划2(需要约3秒)

Answer 1

对我来说，这看起来像是一个直接的参数嗅探问题。

正如您所希望的那样，TOP 1000SQL TimeGeneratedServer 可以扫描索引TimeGenerated并对基表进行查找以评估谓词ApplicationName并在找到第 1,000 行时停止，或者它可以执行聚集索引扫描，查找与谓词匹配的所有ApplicationName行然后做TOP N一些这样的事情。

SQL Server 维护字符串列的统计信息。如果它认为许多行最终将与谓词匹配，则更有可能选择第一个计划，ApplicationName但是该计划并不真正适合作为参数化查询重复使用，因为如果很少有行匹配，它的效率可能会灾难性地低下。如果匹配项少于 1,000 个，则肯定需要执行与表中行数一样多的键查找。

通过这一端的测试，我无法找到任何添加或删除冗余ESCAPE更改的 SQL Server 基数估计的情况。当然，更改参数化查询的文本意味着原始计划无法使用，并且需要编译一个不同的计划，该计划可能更适合当前考虑的特定值。