用安装向导安装了全新的SQL Server，最后你点击了完成按钮。哇噢~~~现在我们可以把我们的服务器进入生产了！
抱歉，那并不是真的，因为你的全新SQL Server默认配置是未优化的，一个合格的DBA一定会对默认安装中配置进行修改。
当然，如果你只是学习用途，默认配置微软确实已经做得很好。
但服务器进入生产，为了更快的性能，在SQL Server安装完成后3个你需要立即修改的配置选项。
1. 最大服务器内存（Max Server Memory）
这是一个很不好的默认配置。SQL Server默认可以吃光你整个物理内存！
你总应该改变这个配置选项，这样的话你可以给系统一些内存，让它可以活着喘气。一般来说（在服务器上没有其它程序/进程）你应该留给操作系统至少10%的物理内存。
这就是说你需要调低最大服务器内存设置。有64GB的物理内存我会配置最大服务器内存为56GB，这样的话系统可以用剩下的8G来消耗和工作。
2.并行开销阈值（Cost Threshold for Parallelism）
这里你配置的数字定义查询成本，查询优化器用它来找更便宜的并行执行计划。如果找到的并行计划更便宜，这个计划会被执行，不然串行计划会被执行。从刚才的图你可以看到，
SQL Server默认配置使用5的成本阈值。当你的串行计划查询成本大于5，然后查询优化器再次运行查询优化来找更便宜并行执行计划的可能。
遗憾的是，5的成本值当下来说是个很小的数字。因此SQL Server太快尝试并行你的执行计划。当你处理更大的查询并行才有意义——例如报表或数据仓库情形。
在纯OLTP情形下，并行计划象征着糟糕的索引设计，因为当你有缺失索引时，SQL Server需要扫描你的整个聚集索引（在与过滤（Filter）和剩余谓语（residual predicate）组合里），
因此你的查询成本越来越大，它们穿过成本阈值，最后查询优化器给你并行计划。当人们看到并行计划时，总会担心！但问题根源是缺失非聚集索引。
对于并行的成本阈值，我总推荐至少20，甚至50。那样的话，你确保SQL Server只为你对更大的查询进行并行。即使在你面前有个并行计划，
你也应该考虑下可否通过增加一个支持的非聚集索引来是这个查询成本更低。另外，CXPACKET并不象征着在你的系统里你有并行问题！
3.最大并行度（Max Degree of Parallelism (MAXDOP)）
如你所见，SQL Server使用默认值0。这个值意味着SQL Server尝试并行化你的执行计划穿过分配给SQL Server的所有CPU内核（默认情况所有内核都分配给SQL Server！）。
你应该能看出这样的设置没有意义，尤其当你有大量CPU内核的系统。并行化本身带来负担，一旦你使用越多的工作线程，这个负担越大。
一个建议是设置最大并行度为在一个NUMA结点里拥有的内核数。因此在查询执行时，SQL Server会尝试在一个NUMA结点里保持并行计划，这也会提高性能。
有时你也会看到建议去设置最大并行度为1。这个是不好的建议，因为这个使你的“整个”SQL Server 单线程！即使维护操作（例如索引重建）已单线程执行，这会严重伤及性能！