在“编辑->首选项->SQL编辑器->MySQL会话”中修改“读取超时”时间

如果你的查询有blob数据，这个问题可以通过应用my.ini更改来修复，就像在这个答案中提出的那样:

[mysqld]
max_allowed_packet=16M

默认情况下，这将是1M(允许的最大值是1024M)。如果提供的值不是1024K的倍数，它将自动舍入到1024K的最接近倍数。

虽然引用的线程是关于MySQL错误2006，设置max_allowed_packet从1M到16M确实修复了2013年的错误，当我运行一个长查询时出现。

对于WAMP用户:您将在[wampmysqld]部分中找到该标志。

如果这里所有其他解决方案都失败了，请检查您的syslog (/var/log/syslog或类似)，看看您的服务器在查询期间是否内存不足。

当innodb_buffer_pool_size设置得太接近物理内存而没有配置交换文件时出现此问题。MySQL建议将innodb_buffer_pool_size设置为物理内存的80%左右，我将其设置为90%左右，内核正在杀死MySQL进程。将innodb_buffer_pool_size移回80%左右，解决了这个问题。

对我来说，以上都没用。然后我尝试停止mysql服务，并再次启动它，神奇地查询开始运行:D。

$ sudo service mysql stop
$ sudo service mysql start

希望这能有所帮助

首先检查索引是否到位。

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

此错误消息有三个可能的原因

通常这表明网络连接有问题，如果经常发生这种错误，您应该检查网络的状况 有时，当数百万行作为一个或多个查询的一部分发送时，就会出现“during query”形式。 更罕见的情况是，当客户端尝试到服务器的初始连接时，也会发生这种情况

更多细节请阅读>>

原因2:

SET GLOBAL interactive_timeout=60;

从默认的30秒到60秒或更长时间

原因3:

SET GLOBAL connect_timeout=60;