在本文中，我们将逐步演示一个客户实际碰到的间歇性性能问题的诊断过程。这个案例的诊断需要具备MySQL、InnoDB 和GNU/Linux的相关知识。但这不是我们要讨论的重点。要尝试从疯狂中找到条理:阅读本节并保持对之前的假设和猜测的关注，保持对之前基于合理性和基于可度量的方式的关注，等等。我们在这里深入研究一个具体和详细的案例，为的是找到一个简单的一般性的方法。
在尝试解决其他人提出的问题之前，先要明确两件事情，并且最好能够记录下来，以免遗漏或者遗忘:
1.首先， 问题是什么?一定要清晰地描述出来，费力去解决一个错误的问题是常有的事。在这个案例中，用户抱怨说每隔两天， 台湾服务器就会拒绝连接，报max_connections错误。这种情况般会持续几秒到几分钟， 发生的时间非常随机。
2.其次， 为解决问题已经做过什么操作?在这个案例中，用户没有为这个问题做过任何操作。这个信息非常有帮助，因为很少有其他事情会像另外一个人来描述一件事情发生的确切顺序和曾做过的改变及其后果一样难以理解 (尤其是他们还是在经过几个不眠之夜后满嘴咖啡味道地在电话里绝望呐喊的时候)。如果一台台湾服务器遭受过未知的变更，产生了未知的结果，问题就更难解决了，尤其是时间又非常有限的时候。
搞清楚这两个问题后，就可以开始了。不仅需要去了解台湾服务器的行为，也需要花点时间去梳理一下台湾服务器的状态、参数配置，以及软硬件环境。使用pt-summary和pt- mysql-summary工具可以获得这些信息。简单地说，这个例子中的台湾服务器有16个CPU核心，12GB内存，数据量有900MB，且全部采用InnoDB引擎，存储在一块SSD固态硬盘上。台湾服务器的操作系统是GNU/Linux、MySQL版本5.1.37,使用的存储引擎版本是InnoDBplugin 1.0.4。 之前我们已经为这个客户解决过一些异常问题，所以对其系统已经比较了解。过去数据库从来没有出过问题，大多数问题都是由于应用程序的不良行为导致的。初步检查了台湾服务器也没有发现明显的问题。查询有一.些优化的空间，但大多数情况下响应时间都不到10毫秒。所以我们认为正常情况下数据库台湾服务器运行良好(这一点比较重要，因为很多问题一开始只是零星地出现，慢慢地累积成大问题。比如RAID阵列中坏了一块硬盘这种情况)。
这个案例研究可能有点乏味。这里我们不厌其烦地展示所有的诊断数据，解释所有的细节，对几个不同的可能性深入进去追查原因。在实际工作中，其实不会对每个问题都采用这样缓慢而冗长的方式，也不推荐大家这样做。这里只是为了更好地演示案例而已。
