sql-server – 当一个早年快速的SQL查询开始运行迟钝时,我在那边

配景

我有一个针对SQL Server 2008 R2运行的查询,它毗连和/或左毗连约莫12个差异的“表”.数据库相等大,有很多表高出5000万行和约莫300个差异的表.这是一家大型公司,在世界拥有10个客栈.全部客栈都读写数据库.以是它很是大并且很是忙碌.

我碰着题目的查询看起来像这样：

select t1.something,t2.something,etc.
from Table1 t1
    inner join Table2 t2 on t1.id = t2.t1id
    left outer join (select * from table 3) t3 on t3.t1id = t1.t1id
    [etc]...
where t1.something = 123

请留意,个中一个毗连位于非相干子查询上.

题目是从本日早上开始,没有任何变革(我或团队中的任何人都知道)到体系,凡是必要约莫2分钟才气运行的查询,开始耗费一个半小时来运行 – 当它运行时跑了.数据库的别的部门正好嗡嗡作响.我已经从它凡是运行的sproc中取出了这个查询,而且我在SSMS中利器具有沟通慢度的硬编码参数变量运行它.

稀疏的是,当我回收非相干子查询并将其抛入姑且表,然后行使它而不是子查询时,查询运行正常.其它(这对我来说是最稀疏的)假如我将这段代码添加到查询的末端,那么查询运行得很好：

and t.name like '%'

我从这些小尝试中得出结论(也许是错误的),减速的缘故起因是因为SQL的缓存执行打算是怎样配置的 – 当查询稍有差异时,它必需建设一个新的执行打算.

我的题目是：当一个曾经快速运行的查询溘然在三更开始迟钝运行时除了这一个查询之外没有其他任何身分受影响,我该怎样办理它以及怎样防备它在未来产生？我怎样知道SQL在内部做什么使它变得云云慢(假如运行错误的查询,我可以获得它的执行打算,但它不会运行 – 大概预期的执行打算会给我一些对象？)？假如这个题目与执行打算有关,那么我怎样让SQL不要以为真正糟糕的执行打算是个好主意呢？

另外,这不是参数嗅探的题目.之前我已经看过了,这不是它,由于纵然我在SSMS中对变容器举办硬编码,我的机能如故很慢.

办理要领

When a query that used to run fast suddenly starts running slowly in the middle of the night and nothing else is affected except for this one query,how do I troubleshoot it…?

您可以起首搜查执行打算是否仍在缓存中.搜查sys.dm_exec_query_stats,sys.dm_exec_procedure_stats和sys.dm_exec_cached_plans.假如如故缓存了错误的执行打算,您可以对其举办说明,还可以搜查执行统计信息.执行统计信息将包括逻辑读取,CPU时刻和执行时刻等信息.这些可以给出凶猛的迹象表白题目是什么(譬喻,大扫描与阻塞).有关怎样表明数据的声名,请参阅Identifying problem queries.

Also,this is not a problem with parameter sniffing. I’ve seen that before,and this is not it,since even when I hard-code the varaibles in SSMS,I still get slow performance.

我不信托. SSMS中的硬编码变量并不能证明已往的错误执行打算没有针对偏斜的输入举办编译.请阅读Parameter Sniffing,Embedding,and the RECOMPILE Options,获取有关该主题的很是好的文章. Slow in the Application,Fast in SSMS? Understanding Performance Mysteries
是另一个很好的参考.

I’ve concluded (perhaps incorrectly) from these little experiments that the reason for the slow-down is due to how SQL’s cached execution plan is set up — when the query is a little different,it has to create a new execution plan.

这很轻易测试. SET STATISTICS TIME ON将向您表现编译与执行时刻. SQL Server:Statistics机能计数器还将显现编译是否是一个题目(坦白地说,我发明它不太也许).

可是,您也许会碰着相同的题目：查询授予门.有关具体信息,请阅读Understanding SQL server memory grant.假如您的查询在某个时候哀求大量授权没有可用的内存,则它必需守候,而且它们看起来都将“迟钝执行”到应用措施.说明wait info stats将显现是否是这种环境.

有关丈量内容和查找内容的更一样平常性接头,请参阅How to analyse SQL Server performance

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!