【问题标题】:Long wait time of SQL QuerySQL Query 等待时间长
【发布时间】:2018-10-11 04:31:16
【问题描述】:

https://www.brentozar.com/pastetheplan/?id=HyuR18hcm

在这个 URL 中我分享了我的执行计划和查询等待了 5940578 毫秒,我通过 Query Store 得到了这个信息,我想知道这个查询等待这么久的原因

请查看提供的链接以获取执行计划和 SQL 查询的详细信息

提前致谢

【问题讨论】:

  • 你在这个表上设置了索引吗?
  • 要么你有非常满的页面并且没有磁盘空间来创建新的页面,要么有触发器或其他涉及的锁阻止了这个查询,你需要在某个地方寻找另一个被阻塞的查询。
  • 最好的解决方案是优化索引,另一种方法是在插入之前禁用索引,在插入语句之后启用它们。

标签: sql sql-server sql-server-2016 sqlperformance


【解决方案1】:

仅根据计划,您在该表上似乎有 20 个索引;这似乎很多。过度索引表会给 INSERT 和 UPDATE 增加大量等待时间,特别是如果 INSERT 导致聚集索引上的页面拆分(例如插入非顺序 GUID)。

【讨论】:

  • 是否有任何替代方案,因为所有这 20 个索引对数据库也很重要?
  • 性能调优是一门艺术,也是一门科学;我首先检查所有这些索引,看看它们是否重叠(例如,一个包括列 a、b、c,另一个包括列 a、b;你可以删除第二个)。之后,找到可以替换为 INCLUDE 的那些。接下来,查看您的插入以确保您没有进行页面拆分。您还应该确保您的维护计划有效。
  • 这很复杂,但要从小处着手,边做边做。
  • 我已经应用了这个东西,我删除了重叠的索引,但它不会影响性能等待时间是相同的,即使我在删除一些重叠的索引后在我的缓存中有多个计划跨度>
  • 我还想补充一点,我仅在 2 个索引上读取为 (56263(cluster),4(noncluster indx))
猜你喜欢
  • 2022-11-03
  • 1970-01-01
  • 1970-01-01
  • 2019-07-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-06-14
  • 2021-04-27
相关资源
最近更新 更多