这是SQL
SELECT tal.TrustAccountValue
FROM TrustAccountLog AS tal
INNER JOIN TrustAccount ta ON ta.TrustAccountID = tal.TrustAccountID
INNER JOIN Users usr ON usr.UserID = ta.UserID
WHERE usr.UserID = 70402 AND
ta.TrustAccountID = 117249 AND
tal.trustaccountlogid =
(
SELECT MAX (tal.trustaccountlogid)
FROM TrustAccountLog AS tal
INNER JOIN TrustAccount ta ON ta.TrustAccountID = tal.TrustAccountID
INNER JOIN Users usr ON usr.UserID = ta.UserID
WHERE usr.UserID = 70402 AND
ta.TrustAccountID = 117249 AND
tal.TrustAccountLogDate < '3/1/2010 12:00:00 AM'
)
Basicaly有一个Users表,一个TrustAccount表和一个TrustAccountLog表.
用户:包含用户及其详细信息
TrustAccount:用户可以拥有多个TrustAccounts.
TrustAccountLog:包含对所有TrustAccount"移动"的审计.一个
TrustAccount与多个TrustAccountLog项关联.现在这个查询在SQL Server Management …
我已经在Windows 2008R2中的ASP.NET上运行了.NET 4.5的Entity Framework 4.1.我使用EF代码优先连接到SQL Server 2008R2,并执行相当复杂的LINQ查询,但只产生了一个Count().
我在两个不同的Web服务器上重现了这个问题,但只有一个数据库(当然是生产).它最近开始在Web或数据库端没有应用程序,数据库结构或服务器更改.
我的问题是在某些情况下执行查询需要花费大量时间(接近4分钟).我可以从SQL Profiler中提取实际查询,并在大约1秒内在SSMS中执行.这对我来说是一致且可重复的,但是如果我将其中一个参数("2015-01-22之后的日期"参数)的值更改为更早的内容,例如2015-01-01,或更晚的2015-02- 01,它在EF中工作正常.但我把它重新回到了2015-01-22并再次放缓.我可以一遍又一遍地重复这个.
然后我可以在EF中运行一个类似但不相关的查询,然后回到原始版本,这次运行正常 - 与之前完全相同的查询.但是如果我打开一个新的浏览器,循环就会重新开始.那部分也没有意义 - 我们没有做任何事情来保留用户会话中的数据上下文,所以我不知道为什么会发挥作用.
但这一切都告诉我数据本身很好.
在Profiler中,当查询正常运行时,大约需要一两秒钟,并显示大约2,000,000个读取和大约2,000个CPU.当它运行缓慢时,需要3.5分钟,值为300,000,000和200,000 - 所以读取大约高150倍,CPU高出100倍.同样,对于相同的SQL语句.
有关EF可能采取哪些不同措施的建议,这些建议不会出现在查询文本中？是否存在某种隐藏的连接属性,在某些情况下可能导致不同的执行计划？
编辑
EF构建的查询是使用文本中包含的参数构建巨型字符串的查询之一,而不是SQL参数:
exec sp_executesql
N'SELECT [GroupBy1].[A1] AS [C1]
FROM (
SELECT COUNT(1) AS [A1]
...
AND ([Extent1].[Added_Time] >= convert(datetime2, ''2015-01-22 00:00:00.0000000'', 121))
...
) AS [GroupBy1]'
编辑
我不是将此作为答案添加,因为它实际上并没有解决潜在的问题,但最终通过重建索引和重新计算统计数据来解决这个问题.没有比平时更长的时间,这似乎已经解决了造成这个问题的任何问题.
我会继续阅读这里的一些链接,以防再次发生这种情况,但由于它现在都在工作并且无法实现,我不知道我是否确实知道它到底在做什么.
感谢所有的想法.
我从一个网站查询需要15-30秒,而同一查询在0.5秒内从SQL Server Management工作室运行.我无法使用SQL事件探查器看到任何锁定问题,也无法从SSMS手动重现延迟.一个星期前,我分离并重新连接数据库,似乎奇迹般地解决了这个问题.今天当问题又重新出现时,我只是试图重建索引.这也解决了这个问题.但是,我认为这不一定是索引问题,因为根据我的知识,索引不会在简单的分离/附加上自动重建.
知道什么可能导致延迟吗？我的第一个想法是,可能有一些参数嗅探正在调用的存储过程(所述存储过程运行CTE,如果这很重要)导致错误的查询计划,这将解释问题的间歇性.由于分离/重新附加和索引重建在理论上应该使缓存的查询计划无效,这是有道理的,但我不确定如何验证这一点.另外,为什么在通过SSMS手动运行时,相同的查询(直接从带有完全相同参数的SQL事件探查器复制)会出现相同的延迟？
有什么想法吗？