2011年2月--2011年7月数据库性能优化过程

开始暴露问题
2011年2月下旬的一天早上，昨天更新的系统，早上发现数据库的服务器CPU达到100%，而且持续的时间很长，不得回到昨天更新前的版本，但系统还是有较长时间达到100%的情况，问题没有解决，从这正式开始优化线上数据库性能。

第一阶段优化
分析问题：
一开始老是想找出问题的原因，找了3天还没有头绪，列出以下原因：
1，JOB的耗时存储过程 --太频繁，执行时间长，1,2分钟
2，频繁执行同样的SQL --如查询用户表sys_user 几分钟内执行数千次
3，tempdb太小
4，运行SQL太慢
5，数据库阻塞
但这些原因，都找不出具体的在那块有问题，好像都有，又好像都没有，时间在一天天过去，但是系统还是100%经常发生，严重影响业务使用，这时只能按照以前的优化经验调整优化思路，不找原因，只要是问题就优化，一个一个处理，最终解决系统性能问题：
主要是执行优化方法：
1，删除全部的主键聚集索引，改成唯一非聚集索引
2，删除重建全部索引
3，删除全部外键约束
4，持续优化SQL
5，使用行版本隔离级别
6，根据SQL建立索引
7，安装SQL 2008 SP2补丁 8，禁止读取大量数据未分页的SQL，读出数据必须分页50条。

第二阶段优化
经过一个多月的优化，比以前稳定一些，但系统100%的情况还有发生，这时分析下来，可能存在一些原因：
1,高并发
2,严重系统缺陷
3,死锁
4,缓存问题
5,循环调用SQL
6,长事务
7,未优化的SQL
为跟踪以上出现的SQL，发现以前用的DMVS性能分析视图远远不够，必须使用SQL Profile等其他工具，这期间的确进步很大
1，使用SQL Profile监控工具监控高耗CPU的SQL
2，发现长事务，并优化程序和SQL缺陷
3，发现SQL事务中的执行语句停顿问题
4，跟踪引起死锁SQL，并分析死锁原因和优化
5，使用windows的性能工具分析CPU，Reads发现系统问题
6，使用SSRS和windows的性能工具每天发送CPU跟踪报表。

第三阶段优化
经过一，二阶段优化，系统100%比以前的少了很多，但有一天，看SSRS的CPU报表，突然CPU暴涨到100%，而且第二天还有，通过Profile发现是因为缓存更新的原因，由于后台修改数据会触发缓存更新，一旦后台大量更新数据时，前台就会更新大量缓存，这样一来就要很多个SQL请求，CPU就会暴涨到100%，后来修改了程序缓存策略，该问题解决。

经过这三轮的优化，系统的性能比以前有了明显的改善，系统100%的情况极少。经过这几个月优化，彻底发现以前的知识和经验不足，并一度怀疑自己的能力，为何以前优化系统，1,2个月就大概全部搞定，这次花了这么长时间，可能情况不一样，系统的复杂程度也不一样吧！

2011年3月3日CPU的趋势图



2011年5月3日CPU的趋势图


2011年7月7日CPU的趋势图