增加由"select top“返回的行会使查询变得非常慢。
增加由"select top“返回的行会使查询变得非常慢。
提问于 2011-08-24 15:33:04
在大约2分钟内运行的负载突然变成90分钟的运行，然后手动取消。
这是一个简单的阴影查询：
select fields
into shadow_table
from table
where date = '8/23/2011'date有一个非聚集索引。
如果我将查询更改为选择
top 300000它在2秒内完成top 400000，它在3分钟内运行top 500000我厌倦了等待并取消了它
我们的服务器团队在运行时显示了大量的自阻塞。
有人能提出可能的瓶颈吗？
回答 4
Stack Overflow用户
回答已采纳
发布于 2011-08-24 15:39:17
过时的统计数据.
自阻塞只与并行发生，超长的并行运行(与规范相比)通常意味着过时的状态。这也可能是数据基数的变化。
步骤1应该在源表上运行一个UPDATE STATISTICS WITH FULLSCAN。
Stack Overflow用户
发布于 2011-08-24 15:39:06
遵循经过验证的等待和排队方法来确定瓶颈。
当请求运行并行查询时，分析阻塞的正确方法是深入子任务级别，查看是什么阻塞了每个子任务。一个人永远不应该停留在CXPACKET作为等待类型，或'self块‘作为解释。
select w.last_wait_type,
wt.wait_type,
wt.resource_description,
wt.blocking_session_id,
t.pending_io_count,
r.*
from sys.dm_os_tasks t
left join sys.dm_os_waiting_tasks wt on wt.waiting_task_address = t.task_address
join sys.dm_os_workers w on t.worker_address = w.worker_address
join sys.dm_exec_requests r on t.session_id = r.session_id
where r.session_id = <queryspid>;Stack Overflow用户
发布于 2011-08-24 15:42:41
如果它看起来是这样的--一个档案查询--在运行时不会被更新的记录，那么您可以完全关闭阻塞。其他需要完整性但使用您的记录的查询不会受到影响--它们管理自己的锁定。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/7178172
复制相关文章
相似问题
腾讯云开发者
