今天我们来介绍另一种场景：MySQL 客户端给服务端发送一条 SQL 之后，服务端执行 SQL 的过程中，客户端没有任何通知，就直接断开了连接。

这种情况下，服务端会怎么办？

本文内容基于 MySQL 8.0.32 源码，涉及存储引擎为 InnoDB。

正文

1、两种场景对比

为了和前一篇文章介绍的场景区分开，我们用两个虚构小故事把两种场景放在一起作个对比。

场景一：MySQL 客户端 Ctrl + C，服务端会发生什么？

张三（MySQL 客户端）和李四（服务端）是好朋友，它送给了李四一个礼物（发送了一条 DML/DDL SQL）。

有一天，张三和李四闹别扭，它后悔送礼物给李四了，于是它对李四说：把我送你的礼物还给我（​​Ctrl + C 要求服务端中断 SQL 执行​​）。

李四要先把张三送给它的礼物找出来，才能还给张三。

如果礼物还在（事务还没有提交），李四就能把礼物还给张三（中断执行，回滚事务）；如果礼物不在了（事务已经提交了），也就没法还了。

场景二：MySQL 客户端不辞而别，服务端怎么办？

张三（MySQL 客户端）和李四（服务端）是好朋友，它送给了李四一个礼物（发送了一条 DML/DDL SQL）。

有一天，李四因为一件事情把张三惹毛了。

张三心里很不爽，它要跟李四绝交（直接断开了连接），但对它而言，送出去的礼物就是泼出去的水，它不想收回。

李四的性格大大咧咧，它不知道自己把张三惹毛了，还在美滋滋的欣赏张三送给它的礼物（执行 SQL）。

等它回过头来想找张三的时候，发现找不着了，它才回想起来，可能自己把张三惹毛了，朋友没得做了。

此时，李四要怎么对待张三送给它的礼物呢？

接下来，我们跳出虚构，回归现实，来捋一下场景二的流程。

这种场景只会出现在通过程序连接 MySQL 服务端，程序没有关闭数据库连接就执行结束或者崩溃了

2、客户端不辞而别

MySQL 客户端发送一条 DML/DDL SQL 给服务端，服务端收到之后，就开始吭哧吭哧地执行。

SQL 执行完成之前，客户端再没有给服务端发送任何消息，就直接断开连接了。

SQL 执行过程中，服务端并不能感知到连接已经断开了，它还会一直卖力地执行 SQL。

SQL 执行完成之后，问题来了。

3、服务端怎么办？

（1）先提交事务再回滚

如果服务端执行的是 DDL 语句，一条 SQL 执行完成之后，会自动提交事务。

如果服务端执行的是 DML​ 语句，并且系统变量 auto_commit = on，一条 SQL 执行完成之后，也会自动提交事务。

因为服务端不知道客户端已经断开连接了，事务提交之后，它会把 SQL 执行结果发送给客户端。

把结果发送给客户端，执行的是 send() 系统调用，send() 有两种行为：

行为一，如果 send() 把 SQL 执行结果写入 socket 缓冲区，会返回写入成功，此时，服务端还不会感知到客户端已经断开连接。

send() 执行成功之后，服务端认为这条 SQL 就告一段落了，会等待客户端发送下一条命令。

由于客户端已经断开连接，从当前连接读取下一条命令时会出错。

此时，服务端会感知到客户端已经断开连接了。

行为二，如果 send() 直接把 SQL 执行结果发送给客户端，服务端就能马上感知到客户端已经断开连接了。

不管 send() 发生哪种行为，服务端都会感知到客户端已经断开连接了，无非早一点晚一点而已。

感知到连接断开之后，服务端会回滚事务。

但是，由于执行 send() 之前，服务端已经把事务提交了，这里回滚事务并不会生效。

那么，最终结果就是：服务端对于数据的修改会被持久化，永久生效。

（2）回滚事务

如果服务端执行的是 DML 语句，并且用 begin 或 start transaction 显式开启了事务，一条 SQL 执行完成之后，不会自动提交事务，而是会等待客户端发送下一条命令。

读取下一条命令之前，服务端会执行 send() 系统调用，把当前 SQL 的执行结果发送给客户端。

send() 有两种行为：

​行为一，如果 send() 把 SQL 执行结果写入 socket 缓冲区，会返回写入成功，此时，服务端还不会感知到客户端已经断开连接。

send() 执行成功之后，服务端认为这条 SQL 就告一段落了，会等待客户端发送下一条命令。

由于客户端已经断开连接，从当前连接读取下一条命令时会出错。

此时，服务端会感知到客户端已经断开连接了。

行为二，如果 send() 直接把 SQL 执行结果发送给客户端，服务端就能马上感知到客户端已经断开连接了。

不管 send() 发生哪种行为，服务端都会感知到客户端已经断开连接了，无非早一点晚一点而已。

感知到连接断开之后，服务端会回滚事务​，由于执行 send() 之前，并没有提交过事务，这里回滚事务会生效。

那么，最终结果就是：服务端对于数据的修改会被回滚，相当于没有执行过 DML 操作。

4、总结

前面展开介绍了 MySQL 客户端不辞而别之后，服务端进行的一系列操作，总结起来就 3 条：

第 1 条：如果服务端执行的是 DDL 语句，DDL 会执行成功。

第 2 条：如果服务端执行的是 DML​ 语句，并且系统变量 auto_commit = on，DML 也会执行成功。

第 3 条：如果服务端执行的是 DML​ 语句，并且用 begin、start transaction 显式开启了事务或者系统变量 auto_commit = off，事务会被回滚，DML 相当于没有执行。

5、遗留问题

前面介绍到 send() 有两种行为：

• 先把 SQL 执行结果写入 socket 缓冲区，缓冲区满再发送给客户端。
• 直接把 SQL 执行结果发送给客户端。

这两种行为由操作系统内核决定，目前对于这个机制还没有完全研究清楚，留待后续。

本文转载自微信公众号「一树一溪」，可以通过以下二维码关注。转载本文请联系一树一溪公众号。