【51CTO独家特稿】本文来自于DBA实践第一线，具体情况，具体分析，全程回放，如何解决CPU占用率达100%的过程和全景。
点击”运行” 后，系统进入检测页面，待SQL server profiler运行了一段时间后，将其检测结果保存为trc文件，这个时候，就可以就具体的性能问题着手进行定位分析了，通过trc文件我们发现，Duration出现值大于1000的多次出现，且objectType一般为P(即Stored Procedure类型),由于该web应用访问数据库主体的业务逻辑主体是通过Stored Procedure运行的，通过该文件已经能够实施”精确”方案了，很显然，下一步计划应该是调整表的索引和索引碎片了。
既然有了trc文件，何不让SQL Server 2005的数据库引擎优化顾问”表现”一下，很多人不屑于SQL Server 2005本身提供的工具，总喜欢第三方工具，笔者认为，工具的使用是殊途同归的，关键是能够有益于解决问题，笔者还是立即运行了该工具，并参考了它的分析报告，
选择了要分析负荷trc文件后，点击”开始分析”，一段时间后它将给你优化报告，可以择其善者而从之。笔者通过一番比较和研究发现它给出的一些索引和信息重建确实比较合理，故在SQL server management studio 中执行了这些重建索引和静态信息的语句，执行之后，效果比较明显，SQL SERVER 2005的CPU占用率已经回落到平均50%^左右了。此时，夹在心里的一块石头算是落地了，但是革命尚未成功，同志仍须努力，紧接着笔者继续调整了很多重要大表的索引和静态信息计划的重建，并且对索引碎片也进行了重新组织，并且更改了备份计划，让每天备份完成后自动进行索引碎片重新组织的任务，如下图：
 |
在持续调整优化表和索引，并且重新组织索引碎片后，SQL SERVER 2005的CPU再度从平均50%下降到10%左右了。
这个结果也表明，通过笔者持续努力，已经取得了解决CPU占用率100%的阶段性成绩，随着网站用户量的进一步提升，数据库并发性能和吞吐量将面临进一步的考验。