台湾云服务器间歇性的问题比如系统偶尔停顿或者慢查询，很难诊断。有些幻影问题只在没有注意到的时候才发生，而且无法确认如何重现，诊断这样的问题往往要花费很多时间，有时候甚至需要好几个月。在这个过程中，有些人会尝试以不断试错的方式来诊断，有时候甚

至会想要通过随机地改变一些台湾云服务器的设置来侥幸地找到问题。

        尽量不要使用试错的方式来解决问题。这种方式有很大的风险，因为结果可能变得更坏。这也是种令人沮丧且低效的方式。如果一时无法定位问题,可能是测量的方式不正确，或者测量的点选择有误，或者使用的工具不合适(也可能是缺少现成的工具，我们已经开发过工具来解决各个系统不透明导致的问题，包括从操作系统到MySQL都有)。

        为了演示为什么要尽量避免试错的诊断方式，下面列举了我们认为已经解决的一些间歇性数据库性能问题的实际案例:

●应用通过curl从一个运行得很慢的外部服务来获取汇率报价的数据。

●memcached缓存中的些重要 条目过期，导致大量请求落到MySQL 以重新生成缓存条目。

●DNS查询偶尔会有超时现象。

●可能是由于互斥锁争用，或者内部删除查询缓存的算法效率太低的缘故，MySQL 的查询缓存有时候会导致服务有短暂的停顿。

●当并发度超过某 个阑值时，InoDB 的扩展性限制导致查询计划的优化需要很长的时间。

        从上面可以看到，有些问题确实是数据库的原因，也有些不是。只有在问题发生的地方通过观察资源的使用情况，并尽可能地测量出数据，才能避免在没有问题的地方耗费精力。不再多费口舌说明试错的问题，而是给出我们解决间歇性问题的方法和工具，这才
是“王道”。