前言：
SQLServer提供了一个系统存储过程，SP_Configure，可以帮助你管理实例级别的配置。微软建议使用默认配置，但是基于不同的服务器、不同负载的系统和你的用法，更改配置可能会给你的性能带来好处。在32位和64位系统中，sp_configure会有一些差异。
我们经常见到SQLServer所在的服务器上还包含了如IIS、文件服务器或者域控制器这些服务或者功能。这些会影响你的性能甚至对正常运作有阻碍作用。
本系列文章将包含：
1、 为SQLServer配置更多的处理器。
2、 32位和64位系统中的内存配置。
3、 配置“对即时负载的优化”。
4、 优化SQLServer实例的配置。
配置SQLServer以使用更多的处理器：
今时今日的系统，数据库变得越来越大。为了更快地从数据库获取信息，仅靠管理你的数据库并不足够，还需要更多的CPU来处理。
不管你如何高效地维护索引和统计信息，你都很难从一个使用低效CPU的SQLServer中获得足够好的响应时间。如何选择合适的CPU用于数据库的运作不在本系列的范围之内，但是我们将演示如何使的你的CPU运作得更加强大和有效。
你是否曾经想过SQLServer在运行查询的时候会使用多少个CPU？用户经常希望通过购买更多、更快的CPU来加快SQLServer的运作，但是更重要的应该是关注在SQLServer在运行时需要用到多少个？
开始工作：
在开始深入之前，需要了解你的服务器上有多少个CPU。可以使用一个SQLServer的DMV，sys.dm_os_sys_info来查找这部分的信息。这个DMV会尝试返回关于计算机和关于资源消耗等方面的信息：
SELECT cpu_count AS 'Cores' ,--逻辑CPU总数
hyperthread_ratio --一个物理CPU的逻辑内核与物理内核的比
FROM sys.dm_os_sys_info
步骤：
1、 为了设置在实例级别上运行查询时用到的CPU数量，执行下面语句：
--0是默认值
sp_configure 'max degree of parallelism', 0
RECONFIGURE WITH OVERRIDE
GO
2、 从语句级别去设置并行度的值，可以使用hint来实现，下面加上SETSTATISTICS TIME来看看不同的并行度的差异：
SET STATISTICS TIME ON
SELECT *
FROM Sales.SalesOrderDetail
OPTION ( MAXDOP 1 )
SET STATISTICS TIME OFF
GO
SET STATISTICS TIME ON
SELECT *
FROM Sales.SalesOrderDetail
OPTION ( MAXDOP 0 )
SET STATISTICS TIME OFF
GO
下面是截图：
分析：
SQLServer 有很优秀的算法体系去决定是否并行运行查询。改写SQLServer的决定需要经验和专业知识。至于使用多少个CPU，这个比较确定的方法就是——试验。
在步骤1中，使用SP_Configure存储过程来把最大并行度设为0，也就是默认值，这个值代表这SQLServer是否生成并行执行计划，如果是，可以使用多少个CPU。如果你设置为4，SQLServer将使用4个核心来处理查询，如果设为1，就不会发生并行度。
在步骤2中，使用OPTION来对特定查询设置并行查询。这里有两个SELECT语句同时执行。第一个查询使用了MAXDOP =1，意味着不使用并行度执行查询，而第二个查询使用了MAXDOP =0，意味着由SQLServer自己决定是否使用并行度运行。
在加了SET STATISTICS TIME之后，可以看到每个查询总共消耗了多少CPU时间。
扩充知识：
在生产环境中更改默认的最大并行度将会非常危险。所以尽可能保持现状，如果你想修改，需要和你的上司或者同事商讨。经验表明，SQLServer并不总是为了单一查询而使用所有CPU。除此之外，在OLTP系统中，不建议调整这个设置，但是在OLAP系统中，这却是可以考虑的。
另外，如果你有16个核心，并把MaxDegree of Parallelism设为8，并不以为这只有8个核心会用在SQLServer上，仅仅代表单一查询不会使用超过8个核心而已，即使在并行运行，也如此。但是SQLServer依然会使用所有可用的核心。