背景
客户反馈，应用程序经常会报连接失效需要重新建立连接。连接超时主要由interactive_timeout和wait_timeout影响，本篇文章针对这两个参数进行详细介绍。
问题现象
MySQL客户端或应用程序，在与MySQL server建立连接后，如果一段时间没有操作，当再次操作时，常常会报如下错误：
这个报错，意味着当前连接已经断开了。超时的时间，跟interactive_timeout和wait_timeout的设置有关。其中，interactive_timeout针对交互式连接，wait_timeout针对非交互式连接。即，通过MySQL客户端连接数据库是交互式连接，通过JDBC连接数据库是非交互式连接。
原因分析
参数说明
interactive_timeout：服务器在关闭交互式连接前，客户端等待的秒数。
wait_timeout：服务器在关闭非交互式连接前，应用程序等待的秒数。在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。
注意：这两个参数都对新连接生效。
测试验证
interactive_timeout和wait_timeout两个参数是如何相互影响的？
验证1：只修改全局变量interactive_timeout
（1） 交互式interactive_timeout
打开一个MySQL客户端修改interactive_timeout：
打开另一个MySQL客户端查看session级别的wait_timeout：
可以看到，session级别的wait_timeout已经继承了全局的interactive_timeout了。
（2） 非交互式interactive_timeout
打开另一个MySQL客户端，执行脚本查看session级别的wait_timeout:
输出结果：interactive_timeout 20 wait_timeout 3600
可以看到，session级别的wait_timeout没有继承interactive_timeout，依旧是3600。
验证2：只修改全局变量wait_timeout
（1） 交互式修改wait_timeout
打开一个MySQL客户端修改wait_timeout：
打开另一个MySQL客户端，查看session级别的wait_timeout:
可以看到，wait_timeout并没有随着wait_timeout的修改而改变，仍然保持是原来的20。
（2） 非交互式修改wait_timeout
打开另一个MySQL客户端，执行脚本查看session级别的wait_timeout:
输出结果，interactive_timeout 20 wait_timeout 100
可以看到，wait_timeout继承了interactive_timeout的值。
由以上测试可以看出，对于非交互式连接，当前连接wait_timeout继承全局的wait_timeout，对于交互式连接，当前连接wait_timeout继承全局的interactive_timeout。
解决方案
为避免MySQL客户端或应用程序出现连接不可用状态，建议：
- 应用程序：interactive_timeout（或者连带wait_timeout）的值设置要大于连接池超时时间
- MySQL客户端：interactive_timeout（或者连带wait_timeout）的值要大于客户端可能空闲的时间
结论建议
控制连接最大sleep超时时长的参数是：wait_timeout
- 对于非交互式连接，即JDBC连接，当前连接wait_timeout的值继承MySQL Server端全局变量wait_timeout的值；
- 对于交互式连接，即MySQL客户端连接，当前连接wait_timeout的值继承MySQL Server端全局变量interactive_timeout的值。
