好比奥拓比奥迪跑得慢，主要的问题在于发动机（不懂车，随便一说），而不是奥拓车的外型不够流线、轮胎抓地不够好……

　　如果把精力放在改善外型、轮胎这些方面上，确实会让奥拓变得更“快”，但是从原问题（比奥迪慢）上来看，这都是没有意义的。

　　至于如何准确的定位出问题，针对问题又如何下手，这是技术能力，只能依靠不断的学习、长期的积累了。

　　不过依然存在一些比较科学的工作方法，可以让你尽快的抓住重点。如在系统运行正常时采集一份足够完整的性能指标作为基准，当出现状况时再次采集一份相同的指标，对比其中的差异，从差异处入手。

　　经常见到这种人，一听到数据库慢，直接加大内存分配、加缓存、加连接数、加大各种资源配置……典型的胡乱“调优”。

　　调优的层次

　　同一个问题，可能可以从多个方面进行处理。

　　一个慢SQL，优化的方式可能是加个索引、绑定缓存、改写SQL、表分区、甚至是升级硬件。

　　资源争用问题，既可以从配置层面进行优化、减小争用发生的机率，又可以从程序的实现方式上做改变、从源头上避免争用。

　　假设多种处理方式，都可以满足期望，那么应该从哪个层面下手呢？

　　这需要考虑到工作量、效果、隐患等多种因素，当然也不排除几种优化共同作用。

　　调优有效么

　　这是一个工作方法是否科学的问题。

　　每一次试验，都需要能够验证是否有效。有效的保留，无效的则复原。

　　除了对原问题的验证，还必须确认对其他部分是否产生了副作用。理论上这需要在每一次调优尝试后，进行一次足够全面的复测。

　　否则，很容易出现“拆东墙补西墙”的问题。

　　记住以下几个要点：

　　● 每次只改变一处。

　　● 每次改变后进行复测。有效的保留，无效的复原。

　　● 不断的迭代，直到达到预期。

　　只有真正理解调优的目的，并按照科学的方法行动，你的努力才会体现出价值。