MySQL连接因长查询超时断开后，服务端是否继续执行原查询？

MySQL客户端因超时断开连接后，服务端是否继续执行已提交的查询，没有统一的是/否答案，取决于超时触发的位置、连接断开的感知时机、客户端的超时处理逻辑，结合十亿条记录的循环更新场景，具体规则如下：

常见默认场景的行为 #

首先要明确：大部分人遇到的「30秒查询超时」是MySQL Workbench客户端侧的本地超时，不是服务端主动触发的断开。

• 当你点击执行后，SQL语句已经完整发送到MySQL服务端、被服务端接收并进入执行阶段后，Workbench本地倒计时到30秒触发超时，会直接关闭本地对应的TCP连接，这个动作不会第一时间被服务端感知到。
• 服务端默认不会在查询执行过程中主动检测客户端连接状态，只有当执行到需要往客户端回写数据（包括最终执行结果、执行过程中的中间输出）的节点时，才会尝试往TCP连接写数据，此时发现连接已断开，才会终止当前会话的所有操作。

针对十亿条记录的更新场景分两种情况：

• 如果是单条无中间输出的大更新语句（比如单条UPDATE全表扫修改十亿条记录、无额外返回中间信息的逻辑），服务端从开始执行到语句跑完、准备返回「影响行数」之前，都不会尝试和客户端通信，会完整执行完整个更新逻辑、完成数据提交（自动提交开启的场景下），直到准备回传结果时才发现连接断开，此时更新已经生效。
• 如果是存储过程包裹的循环更新，且每轮/每批循环执行后会往客户端输出进度类的中间信息，服务端会在第一次尝试往已断开的连接写中间进度时就感知到连接异常，立刻终止后续执行；已经跑完并提交的批次数据会保留，未执行的批次不会继续跑。

会触发查询提前终止的特殊情况 #

以下场景下，连接断开的同时（甚至断开前）查询就会被终止，不会继续执行：

• 超时是服务端侧触发的：比如设置了系统参数max_execution_time=30000（单位毫秒），语句执行满30秒时服务端会主动终止查询，和客户端连接状态无关。
• 客户端超时逻辑自带杀查询动作：部分版本的MySQL Workbench、或其他第三方数据库客户端，触发查询超时后不是直接掐断连接，而是会先向服务端发送KILL QUERY [对应连接ID]的指令，服务端收到指令后会立刻终止查询执行。
• 服务端配置了极短的TCP Keepalive探测规则：默认Linux系统的TCP Keepalive探测间隔是2小时，基本不会影响正常查询，但如果手动把探测间隔改到了几十秒级别，服务端会在查询执行过程中主动探测客户端存活状态，发现连接断开后立刻终止会话和查询。

注意：wait_timeout和interactive_timeout两个参数只对空闲连接生效，正在执行查询的连接不属于空闲状态，无论执行多久都不会被这两个参数断开。

内容的提问来源于stack exchange，提问作者Mustafa