Query语句优化的基本思路的了解有助于我们更加深入的了解MySQL Query。Query语句优化的基本思路主要体现在以下几个方面。

    1、优化更需要优化的Query

    为什么需要优化更需要优化的Query？我想这个问题不需要过多的解释。那什么样的Query更需要优化呢？这个问题需要从对整个系统的影响来考虑。哪个Query的优化能给系统整体带来更大的收益，就更需要优化。一般来说，高并发低消耗的Query对整个系统的影响远比低并发高消耗的大。下面可以通过以下一个非常简单的案例分析充分说明问题。

    假设有一个Query每个小时执行10000次，每次需要20个IO，而另一个Query每小时执行10次，每次需要20000个IO。

    首先通过IO消耗来分析。可以看出，两个Query每小时所消耗的IO总数目是一样的，都是200000IO/小时。假设优化第一个Query，从20个IO降低到18个IO，也就是降低了2个IO，则节省了2×10000=20000.而如果希望通过优化第二个Query达到相同的效果，必须要让每个Query减少20000/10=2000IO。可以看出第一个Query节省2个IO即可达到第二个Query节省2000个IO相同的效果。

    其次，通过CPU消耗来分析。原理和上面一样，只要让第一个Query节省一小块资源，就可以让整个系统节省出一大块资源，尤其是在排序、分组这些对CPU消耗比较多的操作中更加明显。

    最后，从对整个系统的影响来分析。一个频繁执行的高并发Query的危险性比一个低并发的Query要大很多。当一个低并发的Query执行计划有误时，所带来的影响只是该Query请求者的体验会变差，对整体系统的影响并不会特别突出，至少还属于可控范围。但是，如果一个高并发的Query执行计划有误，那它带来的后果很可能就是灾难性的，很多时候可能连自救的机会都没有，就会让整个系统崩溃掉。如果是遇到一个并发不太高的Query执行计划有误，至少还可以控制整个系统，不至于系统被直接压垮，甚至连问题根源都难以抓到。

    2、定位优化对象的性能瓶颈

    当我们拿到一条需要优化的Query时，第一件事情是什么？是反问自己这条Query有什么问题？我为什么要优化他？只有明白了这些问题，才能知道需要做什么，才能够找到问题的关键。不能只是觉得某个Query好像有点慢，需要优化一下，然后就开始一个一个优化方法去轮番尝试。这样很可能会消耗大量的人力和时间成本，甚至可能到最后还是得不到一个好的优化结果。这就像看病一样，医生必须要清楚病的根源才能对症下药。如果只是知道什么地方不舒服，然后就开始通过各种药物尝试治疗，那后果可能就非常严重了。

    随意，在拿到一条需要优化的Query之后，首先要判断出这个Query的瓶颈到底是IO还是CPU，到底是因为在数据访问上消耗了太多的时间，还是在数据的运算方面花费了太多资源。

    一般来说，在MySQL5.0系列版本中，可以通过系统自带的PROFILING功能清楚地找出一个Query的瓶颈。