MySQL客户端不辞而别，服务端怎么办？
今天我们来介绍另一种场景：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 执行结果发送给客户端。
这两种行为由操作系统内核决定，目前对于这个机制还没有完全研究清楚，留待后续。
本文转载自微信公众号「一树一溪」，可以通过以下二维码关注。转载本文请联系一树一溪公众号。
网站标题：MySQL客户端不辞而别，服务端怎么办？
转载源于：http://www.shufengxianlan.com/qtweb/news24/461224.html
网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联