在上一篇文章中我们使用了几种方法来确定瓶颈，找到瓶颈，下面再回顾一下：
- LoadRunner压力测试 Windows计数器，这种方法主要是找出大概的性能问题是在哪台服务器，主要是哪个资源紧张。
- ANTS Profiler SQL Server Profiler，这两个工具的完美搭配可以准确的定位性能是出在哪个函数，哪个SQL语句上。
如果性能问题是出在程序上，那么就要根据业务对程序中的函数进行调整，可能是函数中的写法有问题，算法有问题，这种调整如果不能解决问题的话，那么就要从架构上进行考虑，我们是不是应该使用这种技术，有没有替代的方案来实现同样的业务功能？举个简单的例子，假设经过跟踪发现，一个负责生成图表的函数存在性能问题，尤其是在压力测试情况下性能问题尤为严重。原来的图表生成是完全基于GDI 在Web服务器上根据数据进行复杂的绘图，然后将绘出的图片保存在磁盘上，然后在HTML中添加Img标签来引用图片的地址。现在使用GDI 会消耗大量内存和CPU，而算法上也没有太大的问题，那么这种情况下我们就需要考虑修改架构，不使用GDI 绘图的方式，或者是使用异步绘图的方式。既然绘图会消耗大量的服务器资源，那么一种解决办法就是将绘图的操作从服务器转移到客户端。使用SilverLight技术，在用户打开网页是只是下载了一个SilverLight文件，该文件负责调用Web服务器的Web服务，将绘图所需的数据获取下来，然后在客户端绘图展现出来。这样服务器只提供WebService的数据访问接口，不需要做绘图操作。
.net上的优化我暂时不表，今天主要讲数据库的优化。使用ANTS Profiler SQL Server Profiler我们可以精确定位某个业务操作对应的数据库脚本或者存储过程。ANTS Profiler告诉我们一个方法在调用的时候花了10秒的时间，那么我们就可以使用VS打开源代码，找到该放入，然后找到对应调用的存储过程，这里也许一个方法里面调用了多个数据层方法，调用了多个存储过程。将调用的这些存储过程记下了，然后在SQL Server Provider的跟踪文件里面去找调用该存储过程花费的Duration。
ANTS Provider跟踪出调用该方法的时间-SUM(所有调用的存储过程的Duration)=C#中进行逻辑处理的时间 Web服务器和数据库服务器之间网络传输数据的时间
一般企业应用或小型应用中数据库服务器和Web服务器要不是就在同一个机房，同一个局域网，或者干脆是同一台机器，这种情况下网络传输速度是很快的，所以我们不考虑网络传送上面的时间。那么就得出：
C#中进行逻辑处理的时间=ANTS Provider跟踪出调用该方法的时间-SUM(所有调用的存储过程的Duration)
代码中的时间得到了，SQL Server中的时间（也就是Duration字段）得到了，那么就可以判断出打开该页面各个服务器所花费的时间，从而找到我们要优化的方向，是存储过程还是C#代码。如果是存储过程，那么通过查询SQL Server Profiler中内容可以找到具体是哪一个存储过程消耗的时间最长。
“射人先射马，擒贼先擒王。”多个存储过程被调用，如果性能出在数据库服务器上，那么进行性能优化时首先要调优的是最大Duration最大的存储过程，另外还有就是Reads很大的存储过程。如果Duration很大但是Reads和Writes都不算特别大，那么有可能是以下原因：
- 这个存储过程相关的资源正在被其他事务占用，也就是说该存储过程被阻塞所以才花了那么多时间。这种情况只需要把该存储过程提出，多执行几次，看是不是仍然Duration很大但Reads不大。
- 存储过程本身很复杂，里面的T-SQL语句就是五六百行，编译出的执行计划也是一堆，里面进行了大量的逻辑判断、大量函数的调用，这种情况下进行调优就比较痛苦了。实际上这次我调优的这个项目就是如此，抓取出来的存储过程尽是复杂的逻辑，少则两三百行代码，多则五六百行，里面还有大量的用户定义函数的调用。对于这种存储过程，我接下来会专门写篇博客介绍下我们这个项目是如何调优的。
- 程序读取的数据不多，但是需要对数据进行大量的运算。哈希联接、聚合函数、DISTINCT、UNION等都是比较耗CPU的。如果是这种情况那就看能不能建立索引或者改写法进行调优。
前面说的是Duration大而Reads小的情况，当然更常见的情况是Duration和Reads都很大。那么我们就将主要精力集中在如何减小Reads上。造成Reads很多的原因大概有以下几种：
- 没有建立相应的索引。对表t1进行查询，条件是where c2='abc'返回c1,c2,c3三个字段，那么这种情况下如果没有对c2建立非聚集索引（c1是主键，建立了聚集索引），那么这个查询将会进行“聚集索引扫描”，本来可能只查出几条记录的，结果要把表的所有记录都扫描一篇，自然Reads就高了。解决办法就是建立相应的索引，比如这里只需要对c2字段建立非聚集索引，然后将c3字段作为包行列就行了。如果只是最c2字段建立非聚集索引，那么前面说到的查找在进行了“非聚集索引查找”后还会进行“键查找”来找到c3列的值，所以要建立的正确的索引才行。
- 不符合SARG原则。查询如果不符合SARG原则，那么即使建立了索引也没法使用。SARG就是查询参数的意思，具体怎么写才符合SARG，大家可以百度，已经有很多相关文章了，我就不累述。
- 涉及的业务数据量大。也就是说即使建立了正确的索引，查询也符合SARG使用到了该索引，但是由于涉及的数据量太大了，所以Reads仍然很大。这种情况就不能再从索引和查询入手，而只能从数据库的设计入手。是否能够增加适当的冗余字段，对数据库进行反范式化，或者如果数据的实时性要求不高的话则可以建立中间汇总表，使用SQL作业来维护这个中间汇总表，查询的时候只查询该中间汇总表即可。或者是否可以建立索引视图或者计算列，然后在计算列中建立索引的方式进行一个预运算，减小实际查询时涉及的数据量。
- 使用了不当的视图。如果对视图的定义很复杂，涉及的表很多，在查询的时候使用了该视图，但是实际上只用到了视图中的一张或两张表，对视图的查询会造成系统根据视图定义查询其他与该查询不相关的表。所以在使用视图的时候一定要知道视图的定义，不用贪图一时的方便而随便使用视图。
- 不正确的使用了用户定义函数。一个存储过程中几百行代码，出于编写方便，大量的调用了一个用户定义表值函数，而该函数是进行了复杂的查询和运算才返回结果的。如果数次或者数十次的调用该用户定义表值函数，那么就会进行很多这种复杂的查询和运算，自然Reads也就很大了。解决办法是尽量减少对这种复制函数的调用，比如一次调用后就将解决保存在表变量或临时表中，接下来再使用的话就使用该表变量或临时表即可。
如果Duration并不大，但是Reads却很大的查询仍然需要需要进行优化。虽然表现出来消耗的时间并不大，但是由于Reads很多，那么说明要进行大量的IO，在高并发的情况下大量的IO处理不过来会加重磁盘的负担，造成CPU占用率上升，性能降低，这时其Duration就会变大。关于Duration不大但是Reads很大的情况仍然是前面说到的几点情况，建立相关索引、修改查询语句等便可解决。
