DBA无论进行任何形式的SQL Server性能调优都会遇到这样那样的问题。事实上，早在2000年的时候，我就写过一本关于SQL Server性能优化的书，叫做《SQL Server性能调优权威指南》。在那之后不久，Microsoft Operations Manager就问世了，当然还有SQL Server Management Pack，这实在是令人兴奋的事。

　　为什么呢？因为management pack带有性能监视器中的原始数据，而且还添加了一个智能层来帮助DBA区分良好数据和可能造成问题的数据。如果你没有使用MOM或相关工具，只是想搞清楚数据库内部究竟发生了什么，这时你就可以使用性能监视器。

　　下面就是几个关键的指标，你需要特别留意：

　　页分割/秒。当SQL Server需要插入数据到一个8K页面，但此页面已满时，页分割操作就会产生，比如想一个已满的索引中插入新数据。为了把数据插入到正确的位置，SQL Server会从后向前把一半的内容拷贝到新的页面中，然后把新数据插入到原先的页面中，从而完成页分割操作。

　　页分割需要花费一定时间，而且还会造成碎片，特别是对于索引来说。超过100个的页分割就已经算是大量的了。对于磁盘系统速度较快的，这个数字可能还会更大一些。

　　SQL Server可以判断磁盘访问速度，因此它会试图在RAM中缓存信息的关键部分。你可以查看Cache Size来确定有多少个8K页面被缓存在内存中。通常来说，刨去Windows系统和其他应用所占用的资源，这个数字应该与服务器可用物理内存总数相接近。如果SQL Server还在运行而缓存数又很小，那么应该是有人对服务器进行了设置而限制了RAM的使用。

　　批请求/秒。批请求可以告诉你SQL Server正在处理的请求有多少，并通常同服务器CPU使用率相关。当你在计数器上看到1000时，那说明你的服务器已经非常忙碌了。如果这时CPU利用率还没有达到100%，你就需要去检查一下磁盘、内存或者网络的相关瓶颈问题了。

　　作为参考，一个千兆以太网连接每秒可以处理30000个批请求。不用考虑交易/秒计数器，因为它对于整体运行情况来说没有什么参考价值。

　　SQL并发/秒。SQL Server需要编译T-SQL来执行操作，但是服务器在条件允许的情况下肯定会试图重复使用已编译的声明。如果你看到了比较高的数字，通常每秒100就已经很高了，那么就说明进行编译的性能开销过高。这时你需要给SQL更多的缓存来进行这个操作。