在负载较重的MySQL服务器上，有时你偶尔会看到一些连接超时的错误，诸如: Can’t connect to MySQL server on ‘mydb’(110)。如果当时你有多个连接请求，你会发现其它连接却没问题。这类问题开始时很不显眼，且长时间来看几乎可以忽略不计（注：次数不 多），类似于百万分之一的发生率，但是在服务器负载不断加重时，可能出现的频率将有所上升。

如果你对连接进行计时你会发现，连接一般都接近3-9秒。这个时长有时也很诡异，多年前我就曾遇到过一次，当时数据库请求连接被重置，SYN包一直被丢 弃。3秒就有一个SYN包被抛弃，9秒有两被抛弃。如果你也碰到了类似情况，则有可能是你的网络存在问题或你的数据库服务器请求侦听队列溢出，你可以通过 运行netstat -s命令进行检查，可能会返回类似于：侦听队列的Socket发生了38409次溢出，38409个SYN包被丢弃，这就意味着侦听Socket的内核缓 存溢出了，SYN包将不得不被丢弃 -- MySQL并不是在需要时就尽快接受连接。

如果发生了这种情况，有2个调优的地方你可以考虑。
1. Linux内核：net.ipv4.tcp_max_syn_backlog，这参数是用来设置所有Socket内核缓存大小的。我的系统缺省值为2048，其它版本可能不尽相同，如果你的连接并发较大则你可能需要将此值提高到8192左右。具体匹配情况我会在下面介绍。

2.
MySQL参数：back_log，缺省值为50。你可能需将此值设置为1000或更高。同时，你可能提高net.core.somaxconn内核参数值，这个参数是用来设置侦听队列的最大深度。我本人内核中此参数设置的是128，这在很多情况下会偏低。

现在我们来深入研究下这个问题。首先看看MySQL是如何接受连接的。有个主线程将接受所有请求侦听Socket的连接。当有个新连接来到时，主线程将为 新连接创建一个新的Socket，同时创建一个新的子线程或从缓存中取一个子线程来处理这个连接。站在MySQL网络通讯基多线程这点来看，多核是有利 的，但对于主线程来说，多核并没什么用。通常主线程接受连接会很快，但是，如果主线程因为互斥等待或为启动新线程而等待，则侦听队列可能会溢出。我们来看 看，如果一个数据库一般每秒能接受1000个连接，这个值很高，但你可能会碰到更高的。因为连接请求的随机到达特性，有时你可能会看到3000个连接并发。这种情况下，缺省的back_log(50)仅能支撑17毫秒，主线程在某些地方处理稍有停滞超过17毫秒，则有些SYN包将被丢弃。

我建议将tcp_max_syn_backlog和back_log的值调整到足够支撑2秒的连接请求（注：连接请求2秒未超时）。比方说，正常情况下每 秒有100个连接，假设峰值为3倍正常情况，则为300连接/秒，这意味着前面提到的参数至少需设到600。(注：300连接/秒 * 2秒 = 600连接/秒)

将参数设到支持2秒以上请求的意义不大，因为客户端在3秒内未收到应答后将发出新的连接请求。

另外，如果你每秒创建了1000个MySQL连接，你可能有点过了，毕竟创建和销毁1000个连接需使用大量的资源。考虑下使用长连接或连接池吧，至少是那种大部分连接是由应用创建的情况。