好比奥拓比奥迪跑得慢，最主要的问题在于发动机（不懂车，随便一说），而不是奥拓车的外型不够流线、轮胎抓地不够好……
如果把精力放在改善外型、轮胎这些方面上，确实会让奥拓变得更“快”，但是从原问题（比奥迪慢）上来看，这都是没有意义的。
至于如何准确的定位出问题，针对问题又如何下手，这就是技术能力，只能依靠不断的学习、长期的积累了。
不过依然存在一些比较科学的工作方法，可以让你尽快的抓住重点。如在系统运行正常时采集一份足够完整的性能指标作为基准，当出现状况时再次采集一份相同的指标，对比其中的差异，从差异处入手。
经常见到这种人，一听到数据库慢，直接加大内存分配、加缓存、加连接数、加大各种资源配置……典型的胡乱“调优”。
调优的层次
同一个问题，可能可以从多个方面进行处理。
一个慢SQL，优化的方式可能是加个索引、绑定缓存、改写SQL、表分区、甚至是升级硬件。
资源争用问题，既可以从配置层面进行优化、减小争用发生的机率，又可以从程序的实现方式上做改变、从源头上避免争用。
假设多种处理方式，都可以满足期望，那么应该从哪个层面下手呢？
这就需要考虑到工作量、效果、隐患等多种因素，当然也不排除几种优化共同作用。
调优有效么
这是一个工作方法是否科学的问题。
每一次试验，都需要能够验证是否有效。有效的保留，无效的则复原。
除了对原问题的验证，还必须确认对其他部分是否产生了副作用。理论上这就需要在每一次调优尝试后，进行一次足够全面的复测。
否则，很容易出现“拆东墙补西墙”的问题。
记住以下几个要点：
● 每次只改变一处。
● 每次改变后进行复测。有效的保留，无效的复原。
● 不断的迭代，直到达到预期。
只有真正理解调优的目的，并按照科学的方法行动，你的努力才会体现出价值。
