性能优化之SQL优化经验总结1: 如何寻找瓶颈在哪里

前言:

你写的程序运行太慢怎么办? 一般来讲, 现在的内存大小已经不是问题, 一般项目里面也用不到很高深很复杂的算法, 因为算法的原因导致的性能瓶颈可能不会太普遍. 除了内存那就只剩下磁盘了, 一般的软件产品都会使用到数据库. 数据库使用, 查询, 计算的性能好坏很大程度上决定了整个产品性能的好坏. 这里笔者总结了一些实际项目中进行性能优化的一些小经验, 本篇主要记录一下如何寻找数据库查询的瓶颈, 大多数提到的想法经验应该是适用于各种数据库的, 某些点可能对Windows的SQL Server2008更加有针对性.

如何寻找瓶颈在哪里:

可以从以下几方面去考虑:

(1) 单条的执行时间长不长? 一般来讲那种正常普通并且确实要去access磁盘的SQL query查询的duration应该3ms左右: 所以可以看有没有某一条SQL特别花时间的, 如果有的话就找这种SQL语言进行单条query级别上的优化, 是不是可以提高这条SQL的性能(比如减少select里面的不使用的attribute, 尽量避免select *, create index之类的), 减少磁盘的读写.

  • 对于这种优化可以查看这条SQL的执行计划(exection plan)看时间主要花在哪个stage, 比如某些SQL查询可能需要Sort, Sort可能占总体时间的70%, 那么可能要想办法去优化Order By里面的东西.

(2)  DISK速度快不快, DISK速度也是影响性能的关键, 但是这个属于硬件级别的因素, 现在看来应该属于比较次要的, 可以不用太关注.

(3) 如果上面都没有问题, 那么是不是看一下总的SQK的数量, 比如如果有两万条SQL查询, 每条3ms, 那么你想想, 这些就要一分钟, 另外笔者发现, 一般来讲SQL本身的执行速度, 都不会太慢, 慢主要是需要从磁盘把结果集读入到内存, 比如使用Collect(“keyName”, &ullMemoryContent); 这个步骤往往才是花时间的, 使用数据库软件执行查询得到结果集并不是一个很费事的过程, 依靠那些软件本身的优化(缓冲区什么的), 执行SQL查询去算结果集应该都比较快. 得到结果集以后要把真是数据写到内容变量里面, 这个就是从磁盘到内存的过程, 就会比较慢.

结束语:

找到瓶颈以后, 接下来就到了真正的优化阶段, 优化的手段太多, 要想全部总结完是不可能的, 况且每种情况都有自己的特征, 不一定能通用, 下一篇笔者会针对(1) 和 (3)整理一些自己遇到的问题并且如何使用优化方案和技巧去解决遇到的性能瓶颈.

Written on July 11, 2014