前面两篇文章我们和大家一起讨论到了SharePoint IIS的应用池回收，W3WP进程数和重置回收等方面的优化，今天来和大家讲讲后端SQL服务器的优化。

对于SQL的优化，今天主要介绍的就是两点，CPU的优化和内存的优化。

很多同学在装好SQL之后，其实并没有对内存优化进行设置，导致SQL的内存分配很不合理，针对于SharePoint，建议设置SQL的使用内存最少为 8192 MB，最多为 20480 MB 这个临界值。

如上设置，注意，这里的配置值和运行值一定要配置两次，并且要保证其一直，否则不会生效，如果不匹配，多点击几次即可。

默认情况下，这两个值的设置是不一样的，需要我们点击配置项，点击确定保存，再输入值，点击运行项目，再点击确定。多设置几次，两个地方反复点OK，多试几次。

OK，说完内存，现在我们来说下CPU，在一个SharePoint环境里面，或者私有云环境里面，正常情况下，SQL的CPU应该至少要跑在 40% ，伴随着硬盘会有频繁的读写IO。

如果CPU占用不高，磁盘IO读写也不高，那就是SQL拖了后腿，SQL一旦拖后腿了，前端web服务器再怎么优化和牛X，用户访问也还是会很慢的。

默认情况下，SQL和IIS一样，针对每个请求，也只会有一个人员来为你服务，但是其实SQL本来是可以用很多个人员来为你服务的，用来处理你的query,但是你如果不优化它，它就会偷懒，默认只激活一个服务员为你工作。

同样在SQL实例的处理器选项中，注意下面三个值。

这里建议是128线程起，最多可以开128个线程来并发为前端提供查询服务。

并且勾选 强化SQL优先级。

最后和内存配置项一样，记得在 配置值和运行值上都多设置几次，确保相同的数值生效。

在最大工作线程这个地方，默认是0，就是只开放1个线程来进行服务，也就是说随便你又多少个查询过来，只有一个服务人员接待，后面的查询全部请排队。

OK，在修改了SQL的内存和CPU配置项之后，大家可以尝试重启一下SQL Server服务，或者直接重启服务器，效果还是很明显的。今天的讨论就到这里，欢迎大家一起共同探讨，谢谢大家！