sql server 2012 数据引擎任务调度算法解析（上)
微软在sql server 2012版本之后，引入了新的任务调度算法，这个算法与之前的版本有一些细微的差别。我在这里试着简单描述一下，一些基本概念就不再赘述了，比如NUMA、scheduler、worker什么的，这些内容在网上一搜一大把，如果不了解随便看几篇文章大概也就有所了解了。
让我们从最基本的内容开始：
在sql server 2012版本以前，整个任务的调度是在一个新的连接到达数据库引擎开始的。当新的连接到达后会以轮循的方式在与连接端口绑定的某一NUMA节点上指派一个scheduler(注1) ，之后，这个新的连接会分配给当前节点负载系数最小的一个scheduler，负载系数大致等于分配给scheduler的任务数，需要注意的是这个负载系数与当前节点上的CPU使用率无关
(我们可以通过select scheduler_id,current_tasks_count from sys.dm_os_schedulers 查看scheduler上的当前任务数)
在给连接分配了一个scheduler后，只要这个连接没有断开，分配的scheduler就与这个连接保持着分配关系，即成为了这个连接的首选scheduler。当客户端提交一个命令后，如batch,rpc等，sqlos也会为这个任务指定一个scheduler，并且保持到命令执行完毕。
在为任务分配scheduler时候，sqlos会优先选择当前连接的首选scheduler，但如果连接的首选scheduler负载系数比最低负载scheduler高出20%，那么sqlos会将这个任务分配给同一NUMA节点下的负载系统最小的scheduler
我们来画个图表示一下，假设默认端口1433只绑定了NUMA节点0
连接以及任务分配流程：
- 新连接到达后，会按与端口绑定的NUMA进行轮循选择节点，但我们只绑定了NUMA 0，所以也没什么好选的了
- 在连接到达NUMA 0后，sqlos会把此新连接分配到负载系数最小（10）的sche0上。
- 此连接客户端发出命令，sqlos发现sche0为首选sheduler，且负载系数正常，则直接使用sche0进行任务指派，且负载系数+1=11
- 此时，sche1上的一个空闲连接发出了新的命令，sqlos先判断sche1为这个连接的首选scheduler，但是由于sche1的负载为14，sche0为11,计算14/11= 1.272727,即首选sche1负载已经高于sche0 20%以上，所以sqlos将在sche0上进行任务指派，sche0负载+1,sche1负载不变(注意此连接的首选scheduler没有变，还是sche1,在命令执行完毕后，如果再发出新的命令，还是要再次重复流程4)
以上即是sql server 2012版本以前(包括2012)的基本任务调度算法……可是等一等，不是说2012的算法改了吗，怎么还包括2012？？
这里要说明的是：只有sql server 2012 Enterprise Edition使用了新的算法，其它版本的调度流程没有变，还是同上面写的一致
新连接到达后，一直到给连接指派scheduler都是与之前的流程一致，没有变化，主要变化是在给连接指定了scheduler后，连接发出一个新的命令，sqlos给任务指派scheduler的算法有小小的改变,那么具体的改变是什么呢？？
且听下回……分解
注1：为什么说是与端口绑定的NUMA呢
因为通过tcp端口的建立连接是可以通过设置NUMA掩码的方式进行NUMA绑定，这样可以更合理的分配cpu的使用
假设我们有一个4个NUMA节点的数据库实例，节点的编号分别为3210。此实例上面跑了两条不同的业务线，一个业务线的优先级比较高，比如面向前端用户的OLTP业务；另一个业务线是需要大量计算资源的OLAP后台业务，但是OLAP的业务线对于结果的返回不需要实时性（当然很少OLTP和OLAP业务都使用一个服务器），那么我们可以让OLAP业务只使用一个NUMA节点，各种计算就让它慢慢在哪算，不要占用过多的CPU资源；OLTP分配三个NUMA，保证前台用户的访问有足够资源，那么掩码的设置可以这样：
那我们在配置管理器中设置sql server的侦听端口为下图，重启服务就可以了
