MySQL连接问题浅析

MySQL的客户端，无论是PHP或者Java，都会发起多个连接来提高系统的吞吐量。在云里面的服务器，因为一些设计和实现上的不同，有一些问题被放大了，同时也带了一些新的问题。

连接的超时时间

在Azure里面，所有的TCP连接都会通过Azure最外层的网络负载均衡器(SLB)，负载均衡器有一个很短的空闲超时，缺省在几分钟。当连接超时的时候，负载均衡器不会通知TCP连接的两端，服务器和客户端都不会得到连接断开的通知。这个行为对许多连接池的实现带来了困扰。所以，对于连接超时时间我们的服务缺省设置为120秒，这个时间确定比负载均衡器的空闲超时要短来避免这个问题。

这个时间同时是对一个查询最长的执行时间。因为在查询的时候是没有网络流量的，负载均衡器会认为这个链接是空闲的。

连接池的使用和大小

我们的服务对于链接的建立做了很多优化，基本上建立一个新连接的时间和在本地的MySQL性能接近，但是新建一个连接的代价仍然是不可忽视的，我们建议使用连接池(JAVA)或者长连接(PHP)。实际代码的例子可以参考https://www.windowsazure.cn/documentation/articles/mysql-database-connection-pool

在使用连接池的时候，建议保持一个比较小的最小连接数，这个数字可以通过观察实际应用的平均压力来确定。

连接池最大的链接数是需要通过对应用程序进行性能压力测试以后决定的。在大多数的情况下，我们服务多个版本(MS1-4)的链接数限制并不是最佳性能的链接数，往往更少的链接数能达到更好的性能。比如MS4的链接数限制是750，但它的最佳的输出性能一般发生在链接数在150-200之间，当然这个值和实际的数据库以及查询有非常大的相关性。