1. 参数说明
back_log 参数可以理解为 MySQL 缓存的尚未处理的连接数量，当 MySQL 在短时间内收到非常多的请求时，一时间处于不过来时，这个参数就会起到非常重要的作用。
MySQL 主线程在会花费一些时间来检查连接并且为连接创建新的线程，当短时间内收到大量连接请求时，back_log 参数表示 MySQL 主线程在暂时停止响应新请求之后，可以在内部堆叠多少个请求。如果在短时间内有大量的连接请求，则应当调大这个参数，否则客户端会报获取连接失败的错误。
换句话说，这个值是传入 TCP/IP 连接的侦听队列的大小，这个队列大小，操作系统有它自己的限制，可以查看操作系统 listen() 系统调用的相关文档说明，back_log 的大小不能设置的比操作系统限制的值大。
在 MySQL 5.7.19 源码中，该参数最终传给 listen() 系统调用，如下：
result= listen(mysql_socket.fd, backlog);
back_log：
- 作用范围：Global
- 动态修改：No，不支持动态修改
- 默认值：-1，自动计算，50 + (max_connections / 5)，上限为 900
- 最小值：1
- 最大值：65535
以上是 5.7 的参数值，8.0 版本略有变化，默认值等于 max_connections。
2. 调优场景
该参数通常不需要调整，但在某些场景下，比如短时间内有大量连接时，可以适当调大该参数。
举个例子，使用 sysbench 进行性能压测，1000 个线程并发，在自定义的 lua 脚本里，在 event() 函数中创建连接，执行 SQL，关闭连接。这个场景会频繁地创建连接和关闭连接。如果 back_log 设置的较小，则 sysbench 在执行过程中会报获取连接失败的错误，查看数据库 processlist，发现大量连接处于 login 以及用户认证状态。调大 back_log 值，则会缓解该问题。
上述场景在实际应用中可能很少会出现，因为这种短连接应用，频繁创建和关闭连接，性能差，消耗资源多，容易出错。更合理的方式是使用连接池，保持长连接。
