性能优化是数据库运维人员和中、高级软件开发人员的必备技能，很多时候老司机和新司机的区别就在写出的东西是否优化。

　　博主接触过近千家客户的系统，这些系统都存在着各种各样的性能问题。那么如何透彻的了解我们的数据库性能问题？今天就用一个案例来说明性能优化的那点儿事儿。

　　PS:很多技术人员对优化有一套自己的理解，在阅读本文前请放下你自己的理解。

　　正所谓：跟着博主不迷路，博主带你上高速！

 　 点开案例跟着博主的思路看看优化这些事儿 ： 本文案例Demo

　　优化首先要知道数据库在一个什么样的硬件/软件环境下运行？配置是怎么样的？内存、CPU这些是否能完全被应用？数据库体量多大？

　　首先我们先看一下系统的配置：

　　软件层面，我们要知道我们的操作系统版本，SQL Server版本，以及对应版本的硬件限制（如32位系统不开AWE无法使用超过4G内存、server 2008 标准版最大支持32G内存等）

　　本例中我们可以看出，系统环境没有异常问题，SQL Server的补丁不是最新的，CPU资源不充足，可能CPU会成为系统的瓶颈。

　　全局层面看问题主要指综合服务器的各种指标表象定位系统的瓶颈或问题，在性能优化中最忌讳的就是看到一个指标马上就下手，针对一个指标的判断是盲目的，很可能使问题偏离本身的根本原因，也可能使优化根本无法解决根本问题而只是表象得到了缓解。

　　CPU：在大量时间内CPU的使用率达到100%，说明CPU已经成为瓶颈。

　　内存：内存计数器生命周期在11点时已经降到0，惰性写入器也彪高，说明内存也存在压力，而且比较严重。

　　磁盘：磁盘的平均队列很高（一般系统最佳情况队列应该低于2），并且读队列和写队列都很高。由于内存存在压力，所以现在无法判断磁盘的压力是由于内存不足引起的还是磁盘速度不能满足需要。

 　　其他计数器：

　　可以看到系统中全表扫面的次数比较多，这表明很多查询没有应用索引。

　　系统在11点左右和11点24左右发生大量锁等待，并且等待时间很长（超过150s）

　　通过很多类计数器能综合看出系统的问题。这里不一一细说了