SQL Server 页面查询超时(SOS_SCHEDULER_YIELD等待)
一、问题概述
问题大概是这样的,有一个功能页面经常查询超时,有时候就算能查询出来也要很长的时间,但是有时又会很快。遇到的这种问题在排除掉网络原因之后基本上可以从查询语句上去找原因。
编译查询SQL语句和查询进程等待结果如下:
1.进程等待
2.编译查询
问题分析:
1.等待类型为SOS_SCHEDULER_YIELD并且CPU时长很长
2.而且查询时长基本上都是消耗在编译这块,实际的查询时长不到一秒。
SOS_SCHEDULER_YIELD等待是SQL Server OS调度这块的线程之间的切换的等待。
这里出于不便没有把SQL语句贴上,实际的SQL语句单单子查询就达60多个,查询语句达到200行,导致生成执行计划的时间过长。单个子查询很简单。
二、解决方案
出现上面的这个原因是由于查询语句子查询太多导致编译时间过长,解决办法可以将每一个子查询单独查询赋值到变量,或者把子查询冗余处理。
备注: 作者:pursuer.chen 博客:http://www.cnblogs.com/chenmh 本站点所有随笔都是原创,欢迎大家转载;但转载时必须注明文章来源,且在文章开头明显处给明链接,否则保留追究责任的权利。 《欢迎交流讨论》 |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 地球OL攻略 —— 某应届生求职总结
· 提示词工程——AI应用必不可少的技术
· Open-Sora 2.0 重磅开源!
· 字符编码:从基础到乱码解决