mysql设置interactive_设置Mysql的连接超时参数。The last packet successfully received from the server was xxx mill

mysql链接错误The last packet successfully received from the server was xxx milliseconds ago解决方案

SHOW GLOBAL VARIABLES LIKE '%wait_timeout%';

SHOW GLOBAL VARIABLES LIKE '%_timeout%';

set global interactive_timeout=28800;

https://blog.csdn.net/weixin_44487203/article/details/129592929

错误说明 autoReconnect=true

线上项目偶尔出现错误，这个错误发现是在项目无人操作一段时间后就产生，如果有人操作，那就不会出现。

具体报错信息
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 385,290,819 milliseconds ago. The last packet sent successfully to the server was 385,290,820 milliseconds ago. is longer than the server configured value of ‘wait_timeout’. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property ‘autoReconnect=true’ to avoid this problem.

中文意思大概是：
从服务器成功接收到的最后一个数据包是385290819毫秒前。最后一个成功发送到服务器的数据包是385290820毫秒前。比服务器配置的值“wait_timeout”长。在应用程序中使用之前，应考虑过期和/或测试连接有效性，增加服务器配置的客户端超时值，或使用连接器/J连接属性“autoReconnect=true”来避免此问题。

错误原因：
MySQL数据库一般默认的连接等待时间为28800s(即8小时)，超过8h，数据库会断开这个连接，但是应用不知道这个连接已经被数据库断开，所以链接池认为该连接是有效的，在下次请求时，连接池会把自己认为有效，但是数据库认为无效的连接分配出去，便会导致如上错误；

Mysql服务端查询

查询了mysql数据库的wait_timeout

SHOW GLOBAL VARIABLES LIKE ‘%wait_timeout%’;
SHOW GLOBAL VARIABLES LIKE ‘%timeout%’;

发现确实是8小时

注：这里有两个超时需要注意：
interactive_timeout：

• 指的是mysql在关闭一个交互的连接之前所要等待的秒数，

wait_timeout：

• 指的是mysql在关闭一个非交互的连接之前所要等待的秒数

通过mysql客户端连接数据库是交互式连接，通过jdbc连接数据库是非交互式连接
所以我们要关注wait_timeout这个参数的值

C3P0解决

再去看项目的配置文件，发现没有一项跟连接超时有关

解决办法
1.C3P0连接池
加上idleConnectionTestPeriod:用来配置测试空闲连接的间隔时间,

• 如果发现超时，会自动去掉。默认0，不进行测试，单位s(秒)

更新后的配置文件，idleConnectionTestPeriod只要设置比数据库28800秒（8小时）小就可以，

• 我这边设置的是3600秒即一小时进行检测。

使用连接池druid报错The last packet successfully received from the server was XXX milliseconds ago.（实测解决）

• https://blog.csdn.net/JGMa_TiMo/article/details/130404972

出现场景

跑定时任务执行sql脚本的时候，sql的复杂度特别大，又不想优化，客户端跑需要10几秒，在druid连接池中跑任务就报上面的错误了。完整错误如下：

The last packet successfully received from the server was 10,009 milliseconds ago. The last packet sent successfully to the server was 10,009 milliseconds ago.

分析
引入chatgpt对此错误的分析如下：

• 提问：使用druid查询mysql报错The last packet successfully received from the server was 10,011 milliseconds ago. The last packet sent successfully to the server was 10,011 milliseconds ago.

ChatGPT回答：

这个错误信息通常表示MySQL连接已经超时了，即长时间没有收到新的查询请求。这可能是因为数据库连接处于空闲状态而被MySQL服务器关闭。你可以尝试使用以下方法来解决这个问题：

检查数据库服务器和应用服务器之间的网络连接是否正常，特别是在高延迟或不稳定的网络环境下。

增加数据库连接的超时时间，这可以通过在JDBC URL中添加

"autoReconnect=true

&autoReconnectForPools=true

&connectTimeout=30000

&socketTimeout=60000"

参数实现（具体数值可以根据实际情况调整）。

使用数据库连接池来管理连接，可以更好地控制连接的超时时间和重连逻辑。

检查数据库是否已满，如果数据库已经使用了大量的系统资源，那么此时数据库的性能可能很低，以至于无法响应新的查询请求。

总之，当出现该错误时，除了以上几个方面的问题需要你尝试解决，还可能会涉及到MySQL服务器本身的设置，例如超时时间、缓存设置等，你可以根据实际情况调整这些设置来解决该问题。

引用chatgpt的解决方法，确实可以解决，方案如下：
jdbc连接串：

jdbc:mysql://192.168.10.12:3306/est_deploy?

keepAlive=true

&autoReconnect=true

&autoReconnectForPools=true

&connectTimeout=30000

&socketTimeout=60000

druid的配置（询问gpt给出的合理配置范围如下，查看了下确实挺合理的）：

{
	"initial-size": 10,
	"min-idle": 5,
	"maxActive": 30,
	"timeBetweenEvictionRunsMillis": 50000,
	"validationQuery": "SELECT 1",
	"testWhileIdle": true,
	"test-on-borrow": false,
	"test-while-idle": false,
	"min-evictable-idle-time-millis": 300000,
	"max-evictable-idle-time-millis": 600000
}

mysql设置interactive_设置Mysql的连接超时参数wait_timeout、interactive_timeout

mysql设置interactive

https://codeantenna.com/a/Mst1p3E7pV

interactive
英
/ˌɪntərˈæktɪv/
美
/ˌɪntərˈæktɪv/

adj.
交互式的，人机对话的；相互交流的，互动的

inter
英
/ɪnˈtɜː(r)/
美
/ɪnˈtɜːr/
v.
<正式>埋葬（遗体）


active
adj.
好动的；积极主动的；定期进行的，起作用的；（思想等）活跃的；切实的；（火山）活的；主动语态的；活性的；（疾病）恶化的；服役的；参战的；（动词）表动作的；（电路系统）在运转中的
n.
主动语态

交互式和非交互式 操作

交互式操作：通俗的说，就是你在你的本机上打开mysql的客户端，就是那个黑窗口，在黑窗口下进行各种sql操作，当然走的肯定是tcp协议。

非交互式操作：就是你在你的项目中进行程序调用。比如一边是tomcat web服务器，一边是数据库服务器，两者怎么通信？在java web里，我们通常会选择hibernate或者是jdbc来连接。那么这时候就是非交互式操作。

在之前，我基本上不关系这两个属性，都是用的是mysql服务商推荐的默认值，就是8小时。

但是，从昨天开始，由于在新网租用了一个空间，而他的mysql的wait_time设置了10s，所以引出来一系列的问题，就顺便来研究下。

或者这个标题可以改为“mysql的8小时自动关闭”问题，这个标题你到百度上搜搜，一搜一大堆，但是都没有讲明白，今天我就给大家来说说这两个值。

一、概念（对应的2个属性）

1)interactive_time:是指如果空余Ns(N就是这个属性的值)，那么就会自动关闭mysql的连接。关闭什么样的mysql连接？在之前，我们在《什么是mysql的交互式操作和非交互式操作？》 这篇文章中讲到，mysql是有两种操作方式，那就有两种连接的，一种是交互式，一种是非交互式。而这个属性控制的是交互式。

• 就是你打开一个mysql客 户端黑窗口，进入操作之后，又隔了Ns你不操作了，之后你想继续操作，
• 对不起，mysql会在之前关闭了你的那个连接，mysql会帮你自动重新连接。

2)wait_time:是指如果空余Ns(N就是这个属性的值)，

• 那么会自动kill掉mysql的一部分连接线程。这里的连接就是指的是非交互式连接。

总结下，就是用比较正规的术语讲：

(1)interactive_timeout:

• 参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。

• 参数默认值：28800秒(8小时)

(2)wait_timeout:

• 参数含义：服务器关闭非交互连接之前等待活动的秒数。

• 在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。

• 参数默认值：28800秒(8小时)

这里有引出了另外一个概念：mysql_real_connect(),这个好理解，就是你不管什么连接，是交互式还是非交互式，

• 你要操作mysql之前要必须执行完毕的方法，其实你可以理解成登录mysql，或者拿到mysql的一个连接。

二、如何查看、重新设置这两个值

查看mysql server超时时间：

msyql> show global variables like ‘%timeout%‘;

设置mysql server超时时间(以秒为单位)： 最小设置

msyql> set global wait_timeout=28800;

msyql> set global interactive_timeout=28800;

mysql默认是28800，即8小时。

这是我修改之后的。这是查看方法。

修改这两个值是分为两种修改的。

1. 修改当前会话的这两个属性值。

• 所谓的当前会话就是你当前获取的连接池的连接。比如你打开黑窗口那个会话。
  • 这个修改比较简单，直接set wait_timeout=10;就行了，
  • 你怎么知道这么修改仅仅修改的是当前会话？很简单，你把这个黑窗口关了，你再重新开一个，再重新查，你发现没改 啊。

2)修改全局的属性值。一般这个用的多，你到你的数据库安装包下找到my.ini，

• 在最下面添加wait_timeout=10就可以了，然后重新启动mysql服务，我说的重新启动服务，不是你关闭这个黑窗口，重新启动一个黑窗口。服务在我的电脑右键服务里去找。

现在先说到这里，一会继续。

一、mysql8小时异常

1)异常概念。

大家都知道mysql的8小时自动断开异常吧，百度上一大把。就是由于这个值造成的，这个值mysql默认的是8小时，

• 所以如果你在8小时内，数据库觉得没 有任何人来连接我，
• 那好，我就将所有的现在存在的非交互式连接全部kill掉。

而ssh中，我们一般用的是数据池。就是在tomcat已启动的时候，就向 mysql申请到N(这个N是你配置的)个非交互是连接，以后想要用数据库连接的时候，没有必要一个请求就去重新获取mysql连接，只要从数据池里获取 就可以了。

• 但是现在如果你8小时之内，没有发送请求，
• 那么mysql会自动将所有的非交互是连接kill掉，那这时候，你的数据库连接池里存在的数据库连 接其实是null，是不存在的，
• 你这时候也不判断，继续想用这个链接去请求数据，当然会抛出异常，所抛出的异常Communications link failure due to underlying exception。

2)那么如何解决呢？

原 理很简单，出现这个异常的原因不就是因为连接池里存在着已经不存在的连接，而且你还不知道，你还得用这个原本就被关闭的连接去请求吗？这就好办了，你控制 了不了服务器的mysql(如果你是空间的话)，

那你知道控制自己的数据库连接池了，让连接池增加一个验证功能，就是凡是在从池里拿到连接之后，在用之前 先验证下这个链接是否有效，

**如果有效则可以直接使用，如果无效则重新申请一个连接，这样就不会出现这个异常了。**当然，肯定性能会降低。关于性能为什么降 低，我们稍后会讲，现在来看，如何实现让数据库连接池先验证是否有效再用的功能：

我用的连接池是c3p0，建议使用这个。当然各个连接池的性能优缺点你得根据自己的项目具体分析，这里可不分析我为什么选c3p0了。

所以也就是通过两个动作去维护这个连接池，如图：

3)解决方案的性能问题

A) 检测有效性的性能优化

因为要去时刻检查这个链接是否还有效，所以效率比如会降低，那么如何检查呢？默认的检查方式我现在还真不知道，但是上面一段话说了，

• 如果使用 automaticTestTable 方法进行验证测试连接的有效性，会对性能有所提升。
• 最最上面是 idleConnectionTestPeriod 解决

那我们就来看下这个属性

这 个属性是什么意思呢？就是他会自动的帮你建立一张名字叫C3P0TestTable的表，这种表非常的简单，而且最关键的是里面没有数据，检测的时候，可 以通过连接访问这种表是否能访问的到，如果能访问的到，说明这个链接是有效的，否则说明这个链接已经被mysql kill掉了。

那这张表是我们程序员建立的吗？NO，你不用管，你只要这么配置上，自然会帮你自动建立一张这个表的。

B) testConnectionOnCheckout 性能的优化。因为这个属性是指你从连接池中拿出来的时候，在每一个链接去真正提交，震中拿着这个链接去数据库访问的时候，要做下检查，并不是说，我从连接 池中拿出来，我就做检查，我得等到提交的时候才做检查的，那这样会设计到一个connection提交的问题，在默认的情况下，你发送一个db request就会自动马上去执行，就会马上commit的，如果你配置在事务当中呢，**就是一个action方法对应一个biz方法，这样你只要做一次检 查就行了，**减少了检测的次数。

也就是说，对于这种解决方案的性能优化的宗旨就是减少检测次数、优化检测方法。

二、mysql的wait_timeout值应该设置多少？

如果你不是IDC，你不是往外出租服务器，那么你完全可以设置为默认值8小时就可以了。

• 但是如果IDC往外租用服务器的时候，就得重新设置了，比如新网就是设置为10s的。

但 是这个设置为多大，并不是新网那样随便设置的，因为我发现新网的这个服务器业务压力并不是很大，但是他却设置了一个10s这么小的值，这样反而会更消耗服 务器资源。

• 是，得承认，如果这个值过大的话，很可能会造成大量的无用的闲置的连接存在，对数据库压力过大，但是新网的那个服务器的业务压力并不大啊，你设 置成这么小的数值，很明显，你是在刻意的增加系统服务器的业务压力啊，罪人啊罪人。

所以，设置为多大，得根据你的服务器的压力大小来配置的，可不是随便写一个数就行了的。

版权声明：本文为CSDN博主「weixin_39601929」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_39601929/article/details/113465240

MySQL中的配置参数interactive_timeout和wait_timeout(可能导致过多sleep进程的两个参数)

https://www.pianshen.com/post/810313245937/

1)interactive_timeout:

• 参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。
  参数默认值：28800秒（8小时）

(2)wait_timeout:

• 参数含义：服务器关闭非交互连接之前等待活动的秒数。
  在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。
  参数默认值：28800秒（8小时）

MySQL服务器所支持的最大连接数是有上限的，因为每个连接的建立都会消耗内存，因此我们希望客户端在连接到MySQL Server处理完相应的操作后，应该断开连接并释放占用的内存。

• 如果你的MySQL Server有大量的闲置连接，他们不仅会白白消耗内存，而且如果连接一直在累加而不断开，最终肯定会达到MySQL Server的连接上限数，这会报’too many connections’的错误。
• 对于wait_timeout的值设定，应该根据系统的运行情况来判断。在系统运行一段时间后，可以通过show processlist命令查看当前系统的连接状态，
  • 如果发现有大量的sleep状态的连接进程，则说明该参数设置的过大，可以进行适当的调整小些。

问题：
如果在配置文件my.cnf中只设置参数wait_timeout=100,则重启服务器后进入，执行:

Mysql> show variables like “%timeout%”;

会发现参数设置并未生效，仍然为28800（即默认的8个小时）。
查询资料后，要同时设置interactive_timeout和wait_timeout才会生效。

【mysqld】
wait_timeout=100
interactive_timeout=100

重启MySQL Server进入后，查看设置已经生效。

问题1：这里为什么要同时设置interactive_timeout,wait_timeout的设置才会生效？

问题2：interactive的值如果设置的和wait_timeout不同，为什么Interactive_timeout会覆盖wait_timeout?

问题3：在进行MySQL优化时，因为interactive_timeout决定的是交互连接的时间长短，而wait_timeout决定的是非交互连接的时间长短。

如果在进行连接配置时mysql_real_connect()最后一个参数client_flag不设置为CLIENT_INTERACTIVE，是不是interactive_timeout的值不会覆盖wait_timeout?

**问题4：为了减少长连接的数量，在设 **置优化时是不是可以将interactive_timeout的值设置的大些，而wait_timeout的值设置的小些？但是问题2的描述好像又不允许这样。。。