java连接mysql数据库超时的问题谁遇到过

推测你指的是mysql服务器的超时吧。默认情况8小时无访问mysql会断开连接。通过改配置文件可以改变这个值，但是实际测试效果不好。

mysql方面不好解决就在client端想办法，大多数链接池可以配置在取得链接时检测可用性(据说c3p0连接池可以自动解决，我用的dbcp需要配置)，比如ibatis可以在datasource配置加上<property

name="validationQuery"

value="select

1

from

dual"/>

<property

name="testOnBorrow"

value="true"/>

解决方法：

1 修改几个关键页面或访问比较频繁的数据库访问 *** 作，使用DataAdapter和DataSet来获取数据库数据，不要使用DataReader。

2 在访问数据库的页面上使用数据缓存，如果页面的数据不是经常更新（几分钟更新一次）的话，使用Cache对象可以不用访问数据库而使用缓存中的内容，那么可以大大减少连接数量。

3 修改代码，把使用Connection对象的地方都在Close()后面加上Dispose()调用。

4 建议对数据库 *** 作进行大的修改，建立自己的数据库 *** 作代理类，继承SystemIDisposable接口，强迫释放资源，这样就不会出现连接数量不够的问题了。

解决方案二

解决方法():WEBconfig 里面:在数据库连接加 Max Pool Size = 512;server=local;uid=;pwd=;database=2004;Max Pool Size = 512;">一劳永逸。

解决方案三

估计是连接(Connection)对象没有Close。倒是不必Dispose，而DataReader用完后应该关闭，但不关闭也没问题，只是不关闭的话此连接对象就一直不能用，只要你最终关闭了连接对象就不会出问题。

连接对象在Open后的 *** 作都放在try块中，后面跟一个finally块：connClose();

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

连接数的话可以修改spfile文件来约束

查看当前的连接数：

select count() from v$process;

–数据库允许的最大连接数：

select value from v$parameter where name = ‘processes’；

–修改最大连接数：alter system set processes = 500 scope = spfile;

–重启数据库：shutdown immediate;

startup;

–查看当前有哪些用户正在使用数据

SELECT osuser, ausername,cpu_time/executions/1000000||’s’, sql_fulltext,machine

from v$session a, v$sqlarea b where asql_address =baddress order by cpu_time/executions desc;

连接超时时间的话有很多办法，最常用的是

在你的oracle服务器的 $ORACLE_HOME/network/admin 中的 sqlnetora中设置参数SQLNETEXPIRE_TIME= n n为一个指定的分钟数

当客户端中断，在 n 分钟内就可以自动断开连接。

我猜测：你的程序每次数据库 *** 作完之后有没有CLOSE

用法如下：

DataAdapter对象在DataSet与数据之间起桥梁作用

string strConn="uid=账号;pwd=密码;database=数据库;server=服务器";//SQL Server链接字符串

SqlConnection ConnSql=new SqlConnection (strConn); //Sql链接类的实例化

ConnSqlOpen ();//打开数据库

string strSQL="SELECT FROM 表名1 "; //要执行的SQL语句

SqlDataAdapter da=new SqlDataAdapter(strSQL,ConnSql); //创建DataAdapter数据适配器实例

DataSet ds=new DataSet();//创建DataSet实例

daFill(ds,"自定义虚拟表名");//使用DataAdapter的Fill方法(填充)，调用SELECT命令

ConnSqlClose ();//关闭数据库

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 的维护者们在后续版本更新时忘记更新文档吧。

以上就是关于java连接mysql数据库超时的问题谁遇到过全部的内容，包括:java连接mysql数据库超时的问题谁遇到过、怎么解决sqlhelper 连接超时的问题、如何设置数据库的连接数和连接超时时间等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！