连接Mysql 报2013 lost connection to MYSQL server during query 错误问题解决方案

排查过程梳理如下

1. MySQL 服务宕了

判断是否属于这个原因的方法很简单，进入mysql控制台，查看mysql的运行时长

mysql> show global status like 'uptime';

+---------------+---------+

| Variable_name | Value |

+---------------+---------+

| Uptime | 3520102 |

+---------------+---------+

1 row in set (0.00 sec)

uptime数值很大，表明mysql服务运行了很久了。说明最近服务没有重启过。

2. Mysql连接超时

即某个mysql长连接很久没有新的请求发起，达到了server端的timeout，被server强行关闭。

此后再通过这个connection发起查询的时候，就会报错server has gone away

mysql> show global variables like '%timeout';

+-------------------------------+----------+

| Variable_name | Value |

+-------------------------------+----------+

| connect_timeout | 10 |

| delayed_insert_timeout | 300 |

| have_statement_timeout | YES |

| innodb_flush_log_at_timeout | 1 |

| innodb_lock_wait_timeout | 50 |

| innodb_rollback_on_timeout | OFF |

| interactive_timeout | 7200 |

| lock_wait_timeout | 31536000 |

| net_read_timeout | 30 |

| net_write_timeout | 60 |

| rds_trx_changes_idle_timeout | 0 |

| rds_trx_idle_timeout | 0 |

| rds_trx_readonly_idle_timeout | 0 |

| rpl_semi_sync_master_timeout | 10000 |

| rpl_stop_slave_timeout | 31536000 |

| slave_net_timeout | 60 |

| wait_timeout | 86400 |

+-------------------------------+----------+

17 rows in set (0.01 sec)

wait_timeout 是默认是28800秒，即mysql链接在无操作28800秒后被自动关闭，也就是8个小时。我这里是86400秒，修改的更长了，一整天。但是我是通过客户端刚刚发起了连接，都不成功，所以这个原因基本排除了。

为什么会说网上大多数都是坑呢？因为这个wait_timeout并不是改了配置文件不起作用，也不是非要和那个interactive_timeout一起改，才会生效，只是你在配置文件中配置“wait_timeout = 10”，在mysql里，用show variables like "%timeout%"看到的还是28800

但是，这里实际上已经按你配置的时间在运行了，也就是说配置已经生效了，为什么这里show不出变化，我也不清楚为什么。

就是因为这个，我们花费了大半天的时间来查找程序上的bug

 这个wait_timeout的作用是，设置非交互连接（就是指那些连接池方式、非客户端方式连接的）的超时时间，默认是28800，就是8小时，超过这个时间，mysql服务器会主动切断那些已经连接的，但是状态是sleep的连接。

      而我们后端程序是运行在windows下的，所以安装的myodbc，并使用ado方式连接的，也就是连接池方式，这种方式的坏处是，当服务器端去连接mysql的时候，连接池里的连接已经被mysql主动断开，这时取回的连接就是null，再加上程序里对此没有做判断的话，接下来的对数据库的一系列的操作都会出现问题。

3. Mysql请求链接进程被主动kill 

这种情况和原因二相似，只是一个是人为一个是MYSQL自己的动作

mysql> show global status like 'com_kill';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Com_kill | 0 |

+---------------+-------+

1 row in set (0.01 sec)

我这里是0，也就排除了这种可能性。

4. Mysql请求结果集超过max_allowed_packet 也会出现这样的报错

定位方法是打出相关报错的语句。

用select * into outfile 的方式导出到文件，查看文件大小是否超过 max_allowed_packet ，如果超过则需要调整参数，或者优化语句。

mysql> show global variables like 'max_allowed_packet';

+--------------------+---------+

| Variable_name      | Value   |

+--------------------+---------+

| max_allowed_packet | 1048576 |

+--------------------+---------+

1 row in set (0.00 sec)

修改参数：

mysql> set global max_allowed_packet=1024*1024*16;

mysql> show global variables like 'max_allowed_packet';

我这里仅仅是进行数据库的连接，不太可能是上述原因。

 

经过一番排查，发现都不是上述原因，那么最大的问题就可能是网络连通性问题了

5.Mysql客户端与Server连接有问题

这个事情只能联系运维了，经过运维一番排查，确认原因是：我们公司的对外出口ip变了，阿里云RDS服务器白名单验证失败，导致无法完成连接，所以报出了2013  lost connection to MYSQL server during query error

 

如何查看MYSQL版本？

mysql> select @@version

-> ;

+------------+

| @@version |

+------------+

| 5.7.20-log |

+------------+

1 row in set (0.00 sec)