在我的前一篇文章《通过磁盘阵列和磁盘分区进行SQL Server性能调优》中，我们谈到了正确建立存储对SQL Server性能调优有多么重要。然而，存储并不是SQL Server硬件的唯一部分，也不是在你设计架构时需要详细考虑的部分。

　　SQL Server内存还会影响性能，而如果在SQL Server系统中有太多的内存就是浪费钱，内存太少就又对性能十分有害。遗憾的是，决定你什么时候在系统里需要更多的内存很灵活。当内存出现问题时，你就会发现disk I/O就会增加，同样磁盘列队也会增加。你也会发现buffer cache hit ratio减少、page life会延长。随着内存需求的增加，你就会开始发现日志文件里的错误信息。

　　SQL Server内存的一个重要部分已经分开了，这样一来就造成了性能退化。持续时间：%n秒、工作组(KB)：%w、committed (KB):：%c、内存利用：%u。

　　SQL Server遇到了%o IO请求事件用15秒以上的时间在数据库[%d] (%i)里的[%f]文件上完成。OS文件处理为%h。偏移的最新IO 长度为: %l.。

　　但是这并不是这些错误被报告的唯一的一次，所以你需要和性能监控器metric一起使用来测定内存是否真的太低。

　　在处理SQL Server内存问题方面也有一些解决办法，最简单的就是解决办法就是扩大服务器内存增加可使用的buffer cache的数量。这样做就增加了内存数据量、减少了你的disk I/O。其他的解决办法包括迁移大空间表的集群式索引以及只使用这些表的非集群式的索引，包括Primary Key。

　　在集群式索引用于查找并且使用了集群式的index seeks时就不同了。如果使用了另一个索引，它就不可能减轻任何内存压力，因为集群式的索引并没有在内存里。如果使用了集群式的index scans，那么在不迁移索引的情况下一个新的非集群式的索引可能会有用。

　　如何监控CPU对列（CPU queuing）

　　CPU是硬件的另一个部分，它能够导致潜在的性能问题。大多数人只看CPU的速度或数量。然而就如同磁盘一样，CPU能够成为瓶颈。如果出现了CPU瓶颈，你可能100%不会去查看CPU的性能。CPU拥有命令对列的方式就如同I/O对列一样。命令被下载到CPU队列中，并且执行之前的操作程序等待CPU变得可以使用。由于CPU的速度变得更快了，我们在CPU里面做任何事情的速度也就加快了，但是我们一次也只能做同样多的事情。现在我们可以使用双核、三核、四核以及多核的CPU。这样我们一次能够执行更多的命令。

　　你可以利用SQL Server性能监控器监控你的CPU。你会在System目标下面发现PerfMon，它有一个计算器的名字“处理机队列长度”。几乎任何其他大于零的队列长度都表明你需要增加一些操作程序，这些操作程序是SQL Server都能同时执行的。但是这并不表明需要一个更快的CPU，而是需要一个更多核的CPU。今天最新的服务器每台服务器都支持32核，一些高级的服务器支持64核（当chase按比例范围共同支持64核时）也可以创建（仅仅是某些厂商）。

　　在第一部分和第二部分里，我已经指出了硬件里的一些地方。这些技巧不是解决性能问题最全面的、最终的解决方案。表的设计和索引的调整经常是并且长期是非常重要的。今天的SQL Server有望在更长的时间内做更多的事情，这样才能使硬件调整对数据库平台更加重要。用arsenal里的一些工具解决性能问题，这样你就能从还未或已经行最小限度升级的现存的每项硬件性能。但是当你的确需要购买时，这些技巧有助于你作出正确的决策，做到物有所值。