算法概述
调度从分配NUMA节点开始，使用循环分配的方式，当一下数据库连接来了，先分配给Node1，然后分配给Node2，然后又Node1
分配了NUMA节点之后，再分配调度器scheduler，在同一NUMA节点内根据Load factor来做调度，Load factor可以简单的等同于分配给调度器的任务数量
task分配是根据Load factor来的，如果首选的调度器比其他调度器多了120%的task，那么选择同一NUMA节点内的其他调度器，否则选择首选调度器
SQL Server 2012调度算法只在企业版上做了修改
新的数据库连接分配：新的连接是用环形循环分配，和前面提到的一样。所有的sql server 2012 产品都是这样分配连接的，首先查询目标NUMA节点内所有调度器的负载，然后选择把数据库连接分配给负荷最小的调度器，在连接的生命周期中，这个调度器变为这个连接的首选调度器。
新的数据库连接并没有首选调度器，所以需要在分配的NUMA节点内给数据库连接分配一个调度器，负荷最小的调度器被选中，如上图的例子，task现在在Node1的调度器 sched#2上跑
SQL Server 2012之前和非企业版
这个比较简单，因为SQL Server 2012之前和SQL Server 2012非企业版无法识别NUMA节点，当task进来时，使用首选调度器，如下图，在Node1的调度器 sched#2上跑，当load factor是其他调度器120%以上的时候就需要重新选其他调度器。
SQL Server 2012企业版
在企业版中，对load factor的算法进行了改进，以进一步适应CPU资源管理。
每个调度器scheduler，都有一个以cpu为目标的资源池，并且会对load factor的负载进行跟踪。调度器的Load factor并不是都是一样的120%，而是通过每个资源池的平均cpu负载来做调度，资源池为单位
调度还是以首选调度器开始，如果调度之后，并没有比NUMA节点内的所有调度器平均少80%，那么可以调度，否则做调度平衡，选择可用资源最多的调度器。
调度的例子(笔者认为例子有些错误，所以做了修改)
| Scheduler | RG Pool Target | Pool Runnable Tasks | Avg Pool/Task | |
| 1 | 50 | 10 | 5 | |
| 2 | 50 | 8 | 6.25 | Currently Best Target – More resources to provide for tasks in the same pool |
假设sched1 可以为每个task提供5，那么sched2可以提供6.25
当前平均是 (5+6.25)/2 = 5.625
当有一个任务要分配，首选是调度器sched1，那么如果被分配，可提供 50/11 = 4.545 > 5.625*0.8 = 4.5008
所以分配后结果
| Scheduler | RG Pool Target | Pool Runnable Tasks | Avg Pool/Task | |
| 1 | 50 | 11 | 4.545 | Not below 80th percentile |
| 2 | 50 | 8 | 6.25 |
当前平均= 5.3977 (6.25 + 4.5454/2)
然后又有一个新的task要分配，首选还是调度器sched1
50/12 = 4.1666 < (4.545+6.25)/2 = 4.3181
所以需要做调整，选择资源最多的一个调度器
| Scheduler | RG Pool Target | Pool Runnable Tasks | Avg Pool/Task | |
| 1 | 50 | 11 | 4.5454 | |
| 2 | 50 | 9 | 5.55 | Added task |
当前平均值 5.047 (5.55 + 4.5454 2)
相关Trace Flag，这些TF只有企业版才有效
-T8008：强制调度，不管调度器scheduler提示，总是调度给最小负载的调度器（使用最小load factor或者资源池）
-T8016：忽略负载均衡，总是调度给首选调度器
文章转载自：
https://www.cnblogs.com/Amaranthus/p/3282846.html
原文来自：
https://docs.microsoft.com/zh-cn/archive/blogs/psssql/how-it-works-sql-server-2012-database-engine-task-scheduling
文章经作者授权转载，版权归原文作者所有
图片来源于网络，侵权必删！
