python链接mysql超过最⼤默认连接时间_python连接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下载后的初次使用这个版本的 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 的维护者们在后续版本更新时忘记更新⽂档吧。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。