问题描述
||
其中一个查询(如下所示)需要90秒钟以上的时间才能执行。它从一个很大的表LogMessage返回约500行。如果从查询中删除了“ 0”,它将在几秒钟内执行。同样,如果删除了“ 1”,它将在几秒钟内执行。在第一种情况下,查询计划显示
Key Lookup (Clustered) PK_LogMessage,Index Scan (NonClustered) IX_LogMessage and nested Loops (Inner Join)
。当删除子句“ 0”或“ 1”时,查询计划将更改并显示“ 5”。当我们正在考虑添加更多索引(可能在ApplicationName上)时,我们想了解当前的情况。
该查询是从written6ѭ生成的,以防您怀疑为什么以这种方式编写查询。同样,实际查询更为复杂,但这是表现出相同行为的最短版本。
查询:
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].[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,SORT_IN_TEMPDB = OFF,DROP_EXISTING = OFF,ONLINE = OFF,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,ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
查询计划1(耗时90秒以上)
查询计划2(约3秒)
解决方法
在我看来,这似乎是直接的参数嗅探问题。
您希望由
TimeGenerated
排序的TOP 1000
SQL Server可以向下扫描TimeGenerated
上的索引并针对基表进行查找以评估ApplicationName
上的谓词,并在找到第1,000行时停止,或者可以执行聚集索引扫描,找到所有匹配“ 13”谓词的行,然后对它们进行“ 15”排序。
SQL Server维护有关字符串列的统计信息。如果认为第一个计划更有可能被选中,因为它认为很多行最终都将与ѭ13plan谓词匹配,但是该计划并不真正适合作为参数化查询重用,因为在少数情况下它可能会造成灾难性的低效率行匹配。如果匹配项少于1,000,则肯定需要进行与表中行数一样多的键查找。
通过测试,我无法发现添加或删除冗余“ 17”会更改SQL Server基数估计的任何情况。当然,更改参数化查询的文本意味着不能使用原始计划,并且它需要编译一个不同的计划,该计划可能更适合当前考虑的特定值。
, 为什么所有这些嵌套查询?
下面的代码完成相同的工作
SELECT TOP(1000)
[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\'~\')
ORDER BY [Extent1].[TimeGenerated] DESC
我也同意可以忽略ESCAPE N \'〜\',因为我找不到使用它的理由。
, 首先,我将简化@niktrs指定的查询。即使执行计划似乎忽略了子查询,也使它更人性化,因此更易于操纵和理解。
然后,您有一个INNER JOIN,在我看来,它可能会消失。是否真正需要将INNER JOIN LogMessage添加到LogMessageCategory?您可以使用以下方法进行快速检查。
SELECT LM.CategoryID AS FromLogMessage,LMC.CategoryID AS FromLogMessageCategory
FROM dbo.LogMessage AS LM
FULL OUTER JOIN dbo.LogMessageCategory AS LMC ON LMC.CategoryID = LM.CategoryID
WHERE LM.CategoryID IS NULL OR LMC.CategoryID IS NULL
, 如果这样做,它将如何运行?
Select *
FROM
(your whole scary framework query with the escape N) a
LIMIT 1000
(or the mssql alternative if mssql does not support the correct syntax -- )
因为如果滚动..您有机会继续使用该框架,并从非常糟糕的sql中获得不错的性能(例如...这意味着您创建了完整的rs,然后仅从中选择1k ... )。