这个问题是我之前遇到的，过了很久才想着去解决它，因为这也没多大影响，无非就是再访问一次的问题，后来有一次观察网站的运行情况时，发现这个问题还挺严重，如果一直用，就不会出现问题，如果中间歇一会，再用就会提示数据查询失败，稍后重试，我之前还一直以为是偶尔的数据库问题，这次发现绝对不是数据库的问题，好了，开始着手解决。

　　大概找了一下规律，发现只要休息一会再次使用网页查询就会报错，这个报错是后端查询数据库失败报的，那就看后端的代码，反复看了好几遍，发现没有问题，那为什么会报错呢，网上搜了一下，有人说是数据库的timeout设置问题，我就去查看了一下数据库的timeout数据，显示如下：

这个数据很正常啊，怎么会导致几分钟后，连接就失效了呢？这里我后端是用python写的，数据库的连接使用的是SQLALchemy，SQLALchemy的重连机制在默认情况下是2个小时，这个也没有问题，服务器上的代码不便调试，于是我就在自己的虚拟机上调试一下，发现虚拟机上根本不会出现连接失败的问题，两边的代码是一样的，唯一的区别就是数据库不同，虚拟机使用的是本地的数据库，服务器使用的是另一台服务器的数据库，这时我意识到问题了，之前查询的timeout是当前服务器的，而不是使用到的服务器的，查询数据库服务器的timeout发现数据也是正常的：

后来查询global变量发现问题出现在这里，SHOW GLOBAL VARIABLES LIKE '%timeout';

这里的timeout和interactive_timeout都是100s，难怪会出现每过一段时间数据库连接就中断呢，后来询问了同时这个参数设置的原因，好像是数据采集端使用的是labview写的，为了防止占用太多的连接，所以将该值设置的很短，既然数据库的设置不能改，那就改我们的代码，SQLALchemy中有一项配置是来设置重连机制：SQLALCHEMY_POOL_RECYCLE,将该值设置为小于timeout的值即可，于是将SQLALCHEMY_POOL_RECYCLE = 90，重启服务器的应用，问题解决了。

从这个问题看出，其实有时候一些报错就是某个原因引起的，但是因为查询的位置出错，导致花费了很多额外的时间，就像这个，本来应该查数据库服务器的信息，结果查的是应用服务器的信息（其实这两个服务器的数据库内容是一致的，我做的主从同步，一直想把查询和增删改的数据库分开，这里还没有分开，但是自己意识中错误的认为分开了）。