mysql超时怎么办 mysql超时怎么解决

mysqlcommit超时

mysqlcommit超时是由于太多的请求或响应导致的。

1、调整TCP/IP连接以及MySQL数据库相关参数，以便提高MySQL的性能。

2、也可以尝试添加一点索引来减少MySQL查询的耗时，以及根据需要选择合适的存储引擎。

相关问答

Q1: C3p0连接mysql，超时问题

C3P0连接池连接mysql有时会出现如下错误：

这是C3P0配置的超时时间和mysql超时时间不一致导致的，C3P0为60秒超时，mysql为30秒超时，在30-60之间的时间mysql已经断开连接，而C3P0还维持连接，再次发送请求就会报上面的错误。

解决方法：

1、修改C3P0的maxIdleTime参数为30。

2、修改mysql的wait_timeout参数为60秒。不停机状态下进入mysql命令行，执行set global wait_timeout=60;

Q2: MySQL连接超时自动断开连接应该怎样处理

用Fsocket获取数据时能够控制超时的。

如果用

File_get_contents($url);

可以临时设定环境变量：

设定默认socket超时时间

ini_set("default_socket_timeout", 3);养成好习惯，使用fsocket获取数据。

如果使用Curl，也可以在Curl中控制超时时间：

curl_setopt($ch, CURLOPT_TIMEOUT, 15);

PHP中mysql函数是不提供类似mysql超时选项的，但是php.ini的mysql.connect_timeout可设置

; Maximum time (in seconds) for connect timeout. -1 means nolimit

mysql.connect_timeout = 60

也可以在php脚本中调用设置ini_set();

Q3: MySQL 锁等待超时（Lock wait timeout exceeded）

问题：Lock wait timeout exceeded; try restarting transaction

MySQL版本：5.6.44

官方文档

意思是：InnoDB在锁等待超时过期时报告此错误。等待时间过长的语句被回滚（而不是整个事务）。如果SQL语句需要等待其他事务完成的时间更长，则可以增加 innodb_lock_wait_timeout 配置选项的值；如果太多长时间运行的事务导致锁定问题并降低繁忙系统上的并发性，则可以减少该选项的值。

锁等待超时，可能是出现了死锁，也可能有事务长时间未提交

库：information_schema

表：

查看各表信息

innodb_trx 表

innodb_locks 表

innodb_lock_waits 表

processlist 表

模拟出现死锁

准备一张只有主键的表：t_test (id)

Navicat 新建查询1

Navicat 新建查询2

检查是否锁表

查询当前正在执行的事务

查询当前出现的锁

查询锁等待对应的关系

查询等待锁的事务所执行的SQL

最后，事务2 等待锁超时报错： Lock wait timeout exceeded; try restarting transaction;

通过事务线程ID查找进程信息

win10 查看端口信息

Q4: keepalived下,mysql连接超时

第一种途径使用命令行在mysql提示符下setglobalwait_timeout=1814400这种方式是一种临时方法，重启服务就会返回默认值了。第二种途径修改my.ini配置文件[mysqld]wait_timeout=31536000interactive_timeout=31536000在mysqld下面添加以上两行，后面的数字是时间首先服务中找到mysql，然后右键属性，在可执行文件的路径中，使劲向后拖动鼠标就可以看到my.ini的文件了。

Q5: 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 5.7.20 的源码进行了一些分析。

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

请点击输入图片描述

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

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

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

mysql超时怎么办的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于mysql超时怎么解决、mysql超时怎么办的信息别忘了在本站进行查找喔。