我们有一个查询this is an actual execution plan
正如你所看到的 - Clustered Index Seek占99%。 它还寻找主键(类型 int )。
表来源有275 000行 表 AuthorSource 有2 275 000行。
未使用分区和压缩。
问题是第一次执行需要25-40秒。但第二次运行需要1-2秒。
此外,我们还有在此服务器上运行的复制,队列阅读器和日志阅读器代理
RAM量:4GB
Sql Server使用:3.7GB
我们认为,sql在第一次执行后缓存查询一段时间,这就是第二次运行只需1-2秒的原因。
但无论缓存和其他原因如何,很奇怪,主键索引查询需要20-40秒。
重复此问题。我们提供给查询的任何不同参数 - 我们得到相同的结果:非常长的第一次查询和快速第二次和以下。
可能是我们必须使用的一些额外设置或资源调控器功能?
exec sp_executesql N'
SELECT [Project1].[C1] AS [C1]
FROM ( SELECT CAST(1 AS bit) AS X
) AS [SingleRowTable1]
LEFT OUTER JOIN
(SELECT [GroupBy1].[A1] AS [C1]
FROM ( SELECT COUNT(CAST(1 AS bit)) AS [A1]
FROM (SELECT [Extent1].[Mention_ID] AS [Mention_ID] ,
[Extent1].[Theme_ID] AS [Theme_ID] ,
[Extent1].[Mention_Weight] AS [Mention_Weight] ,
[Extent1].[AuthorSource_ID] AS [AuthorSource_ID1] ,
[Extent1].[Mention_CreationDate] AS [Mention_CreationDate] ,
[Extent1].[Mention_DeletedMark] AS [Mention_DeletedMark] ,
[Extent1].[Mention_AuthorTags] AS [Mention_AuthorTags] ,
[Extent1].[Mention_Tonality] AS [Mention_Tonality] ,
[Extent1].[Mention_Comment] AS [Mention_Comment] ,
[Extent1].[Mention_AdditionDate] AS [Mention_AdditionDate] ,
[Extent1].[UserToAnswer_ID] AS [UserToAnswer_ID] ,
[Extent1].[GeoName_ID] AS [GeoName_ID] ,
[Extent1].[Geo_ID] AS [Geo_ID] ,
[Extent1].[Mention_PermaLinkHash] AS [Mention_PermaLinkHash] ,
[Extent1].[Mention_IsFiltredByAuthor] AS [Mention_IsFiltredByAuthor] ,
[Extent1].[Mention_IsFiltredByGeo] AS [Mention_IsFiltredByGeo] ,
[Extent1].[Mention_IsFiltredBySource] AS [Mention_IsFiltredBySource] ,
[Extent1].[Mention_IsFiltredBySourceType] AS [Mention_IsFiltredBySourceType] ,
[Extent1].[GengineLog_InstanceId] AS [GengineLog_InstanceId] ,
[Extent1].[Mention_PermaLinkBinaryHash] AS [Mention_PermaLinkBinaryHash] ,
[Extent1].[Mention_APIType] AS [Mention_APIType] ,
[Extent1].[Mention_IsFilteredByAuthorSource] AS [Mention_IsFilteredByAuthorSource],
[Extent1].[Mention_IsFavorite] AS [Mention_IsFavorite] ,
[Extent1].[Mention_SpamType] AS [Mention_SpamType] ,
[Extent1].[MentionContent_ID] AS [MentionContent_ID] ,
[Extent2].[AuthorSource_ID] AS [AuthorSource_ID2] ,
[Extent2].[Author_ID] AS [Author_ID] ,
[Extent2].[Source_ID] AS [Source_ID] ,
[Extent2].[Author_Nick] AS [Author_Nick] ,
[Extent2].[Author_UrlBinaryHash] AS [Author_UrlBinaryHash] ,
[Extent2].[AuthorSource_Type] AS [AuthorSource_Type] ,
[Extent2].[Author_Url] AS [Author_Url] ,
[Extent2].[AuthorSource_Description] AS [AuthorSource_Description] ,
[Extent2].[AuthorSource_Gender] AS [AuthorSource_Gender]
FROM [dbo].[Mention] AS [Extent1]
LEFT OUTER JOIN [dbo].[AuthorSource] AS [Extent2]
ON [Extent1].[AuthorSource_ID] = [Extent2].[AuthorSource_ID]
WHERE (
[Extent1].[Mention_DeletedMark] <> CAST(1 AS bit)
)
AND
(
[Extent1].[Mention_IsFiltredByAuthor] <> CAST(1 AS bit)
)
AND
(
[Extent1].[Mention_IsFilteredByAuthorSource] <> CAST(1 AS bit)
)
AND
(
[Extent1].[Mention_IsFiltredByGeo] <> CAST(1 AS bit)
)
AND
(
[Extent1].[Mention_IsFiltredBySource] <> CAST(1 AS bit)
)
AND
(
[Extent1].[Mention_IsFiltredBySourceType] <> CAST(1 AS bit)
)
) AS [Filter1]
LEFT OUTER JOIN [dbo].[Source] AS [Extent3]
ON [Filter1].[Source_ID] = [Extent3].[Source_ID]
WHERE (
[Filter1].[Theme_ID] = @p__linq__49557
)
AND
(
[Extent3].[Source_Type] <> @p__linq__49558
)
) AS [GroupaBy1]
) AS [Project1]
ON 1 = 1
',N'@p__linq__49557 int,@p__linq__49558 int',@p__linq__49557=7966,@p__linq__49558=8
IndexSeeking Performance Information
我们还使用以下简单代码在sql中手动编写查询:
Select COUNT(1) from Mention m inner join AuthorSource auth on m.AuthorSource_ID = auth.AuthorSource_ID inner join
Source s on auth.Source_ID = s.Source_ID where
m.Mention_DeletedMark = 0 AND m.Mention_IsFilteredByAuthorSource = 0 AND m.Mention_IsFiltredByAuthor = 0
AND m.Mention_IsFiltredByGeo = 0 AND m.Mention_IsFiltredBySource = 0 AND m.Mention_IsFiltredBySourceType = 0
AND m.Theme_ID = 7966
and s.Source_Type <> 8
和执行计划与我们发布的相同。
答案 0 :(得分:0)
查询非常多毛,但看起来你错过了Mention.Theme_ID
的索引?
Sql server遇到问题,因为使用了很多<>
,这意味着它不能使用索引,必须获取所有内容然后将其排序。
答案 1 :(得分:0)
在评论中提出Martin's建议之后,答案是了解SQL Server如何构建执行计划并计算首次查询运行所需的磁盘读取操作。
在我们的特定情况下,强制inner hash join
而不是inner join
会按照我们的预期给出结果,并且默认情况下SQL会选择不同的执行计划。