我有一个LINQ to SQL查询生成以下sql：
exec sp_executesql N'SELECT COUNT(*) AS [value] FROM [dbo].[SessionVisit] AS [t0] WHERE ([t0].[VisitedStore] = @p0) AND (NOT ([t0].[Bot] = 1)) AND ([t0].[SessionDate] > @p1)',N'@p0 int,@p1 datetime',@p0=1,@p1='2010-02-15 01:24:00'
(这是从sql Server 2008上的sql Profiler获取的实际sql.)
当我从查询分析器中运行此sql时生成的查询计划是完美的.
它使用一个包含VisitedStore,Bot,SessionDate的索引.
该查询立即返回.
但是,当我从C#(使用LINQ)运行这个方法时,使用了一个不太方便的查询计划,它在60秒内甚至没有返回.此查询计划正在尝试对包含数百万行的群集主键执行键查找.没有机会返回.
我只是不明白的是,EXACT相同的sql正在运行 – 无论是从LINQ还是在查询分析器中,查询计划都不同.
我已经运行了两个查询很多次,现在它们与任何其他查询隔离.日期是DateTime.Now.AddDays(-7),但我甚至硬编码该日期以消除缓存问题.
解决方法
这是一个比较常见的问题,当我第一次看到它也让我感到惊讶.首先要做的是确保您的统计信息是最新的.您可以通过以下方式查看统计年龄：
SELECT
object_name = Object_Name(ind.object_id),IndexName = ind.name,StatisticsDate = STATS_DATE(ind.object_id,ind.index_id)
FROM SYS.INDEXES ind
order by STATS_DATE(ind.object_id,ind.index_id) desc
应在每周维护计划中更新统计数据.要快速修复,请发出以下命令来更新数据库中的所有统计信息：
exec sp_updatestats
除了统计数据之外,您可以检查的另一件事是SET options.在查询分析器和您的Linq2sql应用程序之间可以有所不同.
另一种可能性是sql Server正在为您的Linq2SQL查询使用旧的缓存计划.计划可以在每个用户的基础上进行缓存,因此如果您以不同的用户身份运行查询分析器,那么可以解释不同的计划.通常你可以添加Option(RECOMPILE)到应用程序查询,但我猜这是很难与Linq2sql.您可以使用DBCC FREEPROCCACHE清除整个缓存,并查看是否加速了Linq2SQL查询.
