<img src="https://pic2.zhimg.com/v2-48b1077d5c913dbb62feb6d70d655779_b.png" data-rawwidth="645" data-rawheight="628" class="origin_image zh-lightbox-thumb" width="645" data-original="https://pic2.zhimg.com/v2-48b1077d5c913dbb62feb6d70d655779_r.png">每一个thread在cpu上执行时候都是有一个quantum（时间片）的，当你的quantum用完了而你的任务还没有结束，这个thread就会自己释放CPU，直接进入runnable队列中排队等待下一次执行，这个直接释放CPU再次等待的过程叫yield。我们知道SQL Server中所有的wait都是有一个类型的，这种自己yield CPU并且等待下一次执行的类型就是sos scheduler yield。如果一个thread不yield，那么它的工作就会一次性地被CPU执行完，而其他thread就没有执行机会，这显然是不好的。

每一个thread在cpu上执行时候都是有一个quantum（时间片）的，当你的quantum用完了而你的任务还没有结束，这个thread就会自己释放CPU，直接进入runnable队列中排队等待下一次执行，这个直接释放CPU再次等待的过程叫yield。我们知道SQL Server中所有的wait都是有一个类型的，这种自己yield CPU并且等待下一次执行的类型就是sos scheduler yield。如果一个thread不yield，那么它的工作就会一次性地被CPU执行完，而其他thread就没有执行机会，这显然是不好的。

明白了什么是sos scheduler yield，我们来看看什么导致了scheduler yield。我们已经知道scheduler yield是说一个thread在CPU上疯狂执行直到把自己的这一次的quantum都用完了，也就是说这个thread在执行的过程中需要的所有的resource都是available的，不然它就会进入suspended状态。那么我们想想什么操作会有这样的表现呢？对了就是table scan或者index scan！当一个很大的scan操作需要访问的所有page都在内存并且也不存在page latch无法获得的问题时，这个thread就尽情地scan这些page，但是由于page太多了，quantum用完了都还没有scan完，所以只有忍痛yield CPU等待下一次执行机会。这就是最常见的sos scheduler yield的原因。当然还有其他原因，比如确实是你的CPU不够强大，已经成为系统的瓶颈。但是根据楼主的描述，以前都好着呢，所以这种情况的可能性不大。

建议检查你的stored procedure，看看有没有big scan，是不是需要创建index来speed up the query。