优化的真谛

当今时代，是信息爆炸的时代，各行各业的信息量以惊人的速度在增长，而这些信息又不能随意的丢弃，因为这些信息蕴藏着极大的价值。面对海量的信息，即数据，我们如何使用它们呢？这就给我们如何使用这些数据提出了更高的要求——优化。

优化这个词，对每一个IT人员来说都不陌生，因为当今IT业的每一个角落，都涉及优化，例如：编程、网络、数据库、系统等。虽然，针对IT领域的每一个细小的领域，优化的方式和方法不尽相同，但本质只有一个，那就是使之更高效。

高效这个词，对不同的场景，有不同的意义，例如：在有些场景下，意味着尽快的返回结果；而在另一些场景下，则意味着可以实现更大的吞吐，也就是单位时间内完成更多的任务；而在有些场景下，两者兼而有之，既要让系统单位时间内完成更多的任务，还要让系统尽快的出结果，针对一次整体的、综合性的优化工作，一般是两者的混合。

那么，优化是什么？答：优化就是在获得相同结果的前提下，想办法让系统尽量少干活，或者在不能减少工作量的情况下，提高单位时间内系统完成的工作量。针对前者，就是想办法让系统尽量少做无用功，在返回相同结果的前提下，让系统尽量少干活；针对后者，就是让系统拿出更多的资源，去完成一个任务。而在现实中，优化一般是针对前者，因为在现实工作中，做无用功的现象比比皆是，很多系统50%甚至更高的资源消耗在无用功上，很多时候，一个措施或者动作，就会让系统跑的飞快。

扯了半天，说点具体的吧，本人是搞数据库的，就说数据库，数据库的性能和多方面的因素有关，例如：主机，网络，OS，DB，应用等，一般来说，除非硬件和OS存在严重的问题，默认配置在绝大多数情况下，应该是最高效的，当然也有调整的余地，但效果不会很明显；DB层面的调整，根据具体的环境，这个一般来说是必须的，但也仅限于一些常用的配置，大部分配置或参数不用调整；而应用，在绝大多数情况下，是我们调整的对象，这个因素变化的空间很大，应用虽然会涉及到SQL，但也不仅仅涉及SQL，还包括一些应用设计方面的问题，之前就遇到过因为应用逻辑设计不合理导致性能奇差，同时，也导致DB服务器端性能严重问题的情况，所以，应用端的逻辑设计也是非常关键的，说到应用的逻辑设计，涉及的因素也会很多，例如：应用端使用数据库的方式等。而我们这里要重点讨论的就是SQL，因为SQL这个环节很容易出问题，而且由于海量数据的因素，一旦出问题，会对数据库的性能造成严重影响，也就是今后会越来越被人们重视的SQL TUNING，当然，这只是优化涉及的最重要的一个因素。

SQL TUNING，随着各行业数据的猛增，它越来越被人们所重视，之前数据量少，即使SQL方面出点问题，和不出问题的情况相比，差别没那么大，用户的感知也不会那么明显，但现在不一样了，动辄几十T乃至几百T的数据量，一旦SQL出现问题，就会出现比较严重的后果，现实工作中，这种问题也是屡见不鲜。那么，我们如何确定SQL是否出现了问题呢？大家知道，现在的任何一种RDB，其优化器都是CBO的，这就是说过去那些写SQL时的条条框框现在已经过时，当然，现在CBO在很多时候还不是很完美，在较少的场景中，还是需要人工对SQL的干预和调整，但一般情况下，不需要。那么，确定SQL是否存在问题的方法，只有一种，那就是查看执行计划，其他都是浮云。

那么，我们通过执行计划，怎么来锁定SQL的问题所在呢？这里面有很多的技巧，一般来说，最简单的方法就是先看每个step的cost，看看那个step消耗cost最多，然后，确定下是否属实，很多简单的情况，通过这种方式，就能确定问题所在，但也有些情况下，这种方法不好使，这也是很多人说的：cost根本就不准的问题。大家想想就知道了，cost是优化器根据相关统计信息算出来的，也是优化器赖以选择执行计划的根据，当统计信息有问题时，算出的cost当然是不准确了，所以，当您怀疑这点时，就要去看看统计信息是否存在问题，例如：统计信息缺失或过时，然后确定是否重新收集统计信息，以及收集哪些统计信息，看具体情况而定，当然，也有统计信息没问题，但算出的cost就是不对的情况，这种情况确实存在，但现实中少之又少了，其实，还是看你个人的经验积累了，如果你的经验丰富，功力足够的话，看一眼就能基本确定问题所在了，仅供大家参考。

http://blog.csdn.net/tuning_optmization/article/details/9269549