mysql数据库响应超时怎么办

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客户端中用来设置读取超时时间的参数。在 MySQL 的官方文档中，该参数的描述是这样的：

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int )The timeout in seconds for each attempt to read from the server There are retries if necessary, so the total effective timeout value is three times the option value You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes

也就是说在需要的时候，实际的超时时间会是设定值的 3 倍。但是实际测试后发现实际的超时时间和设置的超时时间一致。

而具体什么时候发生三倍超时，在文档中没有找到。所以对 MySQL 5720 的源码进行了一些分析。

使用 GDB 调试代码找了实际与 mysql server 通信的代码，如下：

其中 vio_read() 函数中，使用 recv 和 poll 来读取报文和做读取超时。net_should_retry() 函数只有在发生 EINTR 时才会返回 true。从这段代码来看是符合测试结果的，并没有对读取进行三次重试。只有在读取 *** 作被系统中断打断时才会重试，但是这个重试并没有次数限制。

从上面代码的分析可以看出，代码的逻辑和文档的描述不符。于是在一顿搜索后，找到了一个 MySQL 的 BUG(Bug #31163)。该 BUG 报告了在 MySQL 50 中，MySQL c api 读取的实际超时时间是设置的三倍，与现有文档描述相符。于是对 MySQL 5096 的代码又进行分析。

同样使用 GDB 找到了通信部分的代码。这次找到了重试三次的代码，如下：

这个版本的 MySQL api 的读写超时是直接使用的 setsockopt 设置的。第一次循环，在 A 点发生了第一次超时（虽然注释写的非阻塞，但是客户端的连接始终是阻塞模式的）。然后在 B 点将该 socket 设置为阻塞模式，C 点这里重置 retry 次数。由于设置了 alarm 第二次以后的循环会直接进入 D 点的这个分支，并且判断循环次数。作为客户端时net->retry_count 始终是 1，所以重试了两次，共计进行了 3 次 vioread 后从 E 点退出函数。

由上面的分析可知，MySQL 文档对于该参数的描述已经过时，现在的 MYSQL_OPT_READ_TIMEOUT 并不会出现三倍超时的问题。而 Bug #31163 中的处理结果也是将文档中该参数的描述更新为实际读取超时时间是设定时间的三倍。也许是 MySQL 的维护者们在后续版本更新时忘记更新文档吧。

如何设置SYBASE数据库连接超时时间

如果是Sybase的客户端工具 比如isql,好像有一个参数 -l login_timeout。 如果是ODBC，OLEDB数据源等，在配置数据源的时候应该有个设置。 如果是PB 的话，应该在连接的时候对 SQLCA 对象有参数可以设置。

原因分析:

查询超时一般来说首先要从sql语句和数据表的结构上找原因，优化sql语句和为数据库的查询字段建索引是最常用的办法。

另外，数据库的查询超时设置一般是sqlserver自己维护的（在你没有修改query wait配置前），只有当你的实际查询时间超过估计查询时间的25倍时，才会超时。

而造成超出估计值那么多的原因有两种可能:

一是估计时间不准确；

二是sql语句涉及到大量占用内存的查询（如排序和哈希 *** 作），内存不够，需要排队等待资源造成的。

解决办法:

A优化语句,创建/使用合适的索引;

B解决第一个问题的方法,更新要查询表的索引分发统计，保证估计时间的正确性，UPDATE STATISTICS 表名;

C增加内存

如果想手动设置查询超时，可以使用以下语句：

sp_configure 'show advanced options', 1 GO RECONFIGURE GO sp_configure 'query wait', 2147483647 GO RECONFIGURE GO

　由于国内各地区的网络状况是存在着差异的，所以，有的地区用“SQL Server 企业管理器”连接数据库时可能出现“超时已过期”的现象。解决方法延长“登录超时”时间 *** 作步骤第一步：打开“SQL Server 企业管理器”第二步：设置“SQL Server 选项”第三步：延长“登录超时时间”

原因是，客户端已经找到了这台服务器,并且可以进行连接,

不过是由于连接的时间大于允许的时间而导致出错

这种情况一般会发生在当用户在Internet上运行企业管理器来注册另外一台同样在Internet上的服务器,

并且是慢速连接时,有可能会导致以上的超时错误有些情况下,由于局域网的网络问题,也会导致这样的错误

要解决这样的错误,可以修改客户端的连接超时设置

Druid连接池及监控在Spring配置如下：

[html] view plaincopy

<bean id="dataSource" class="comalibabadruidpoolDruidDataSource" init-method="init" destroy-method="close">

<!-- 基本属性 url、user、password -->

<property name="url" value="${jdbc_url}" />

<property name="username" value="${jdbc_user}" />

<property name="password" value="${jdbc_password}" />

<!-- 配置初始化大小、最小、最大 -->

<property name="initialSize" value="1" />

<property name="minIdle" value="1" />

<property name="maxActive" value="20" />

<!-- 配置获取连接等待超时的时间 -->

<property name="maxWait" value="60000" />

<!-- 配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒 -->

<property name="timeBetweenEvictionRunsMillis" value="60000" />

<!-- 配置一个连接在池中最小生存的时间，单位是毫秒 -->

<property name="minEvictableIdleTimeMillis" value="300000" />

<property name="validationQuery" value="SELECT 'x'" />

<property name="testWhileIdle" value="true" />

<property name="testOnBorrow" value="false" />

<property name="testOnReturn" value="false" />

<!-- 打开PSCache，并且指定每个连接上PSCache的大小 -->

<property name="poolPreparedStatements" value="true" />

<property name="maxPoolPreparedStatementPerConnectionSize" value="20" />

<!-- 配置监控统计拦截的filters，去掉后监控界面sql无法统计 -->

<property name="filters" value="stat" />

</bean>

2 只要配置initialSize，maxActive就可以,目前这样的配置已经能够使用连接池，加入其实配置性能不好,官方文档里也不没加其它属性，连接池jar包免费下载。

以上就是关于mysql数据库响应超时怎么办全部的内容，包括:mysql数据库响应超时怎么办、如何设置SYBASE数据库连接超时时间、sql 数据库连接超时等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！