浅析MySQL协议——从一个bug谈起

今天拓海与大家分享其中一个：MySQL协议相关的一个bug。在bug的定位过程中，小伙伴们会了解到一些MySQL协议的基本知识和调试方法。

Bug描述

关于bug的描述，这里使用了项目的issue模板，大家在提bug的时候也请一定遵循这个模板。在本文中使用中文描述，但大家提issue的时候记得用英文，毕竟老外也会来看的。

Which version of Sharding-Sphere do you using?

3.0.0.M2-SNAPSHOT

Which project do you using? Sharding-JDBC or Sharding-Proxy?

Sharding-Proxy

Expected behavior

持续正常的INSERT数据。

Actual behavior

循环插入200万数据，当插入到100万左右的时候，客户端无响应。

Reason analyze

客户端无响应可能是Proxy阻塞引起的，也可能是Proxy导致客户端阻塞引起的。

Steps to reproduce the behavior

持续插入数据到100万条以上即可复现。

Bug初步定位

经过初步分析，Proxy日志正常，MySQL里也能查到用户插入的最后一条数据。那么，问题应该就出在最后一条数据插入成功之后。可能有两种情况：1. 插入数据成功后，MySQL返回的消息被Proxy错误解码，导致Proxy异常；2. Proxy返回给客户端的消息编码错误，导致客户端异常。

第一种情况，如果Proxy解码错误，Netty会抛异常，TCP连接断开，Proxy会把异常打印到日志，所以这种情况可能性不大。第二种情况可能性较大，需要分析Proxy和客户端之间的消息交互，进一步定位。

MySQL协议

准确的说应该是MySQL Client/Server协议，另一个叫X Protocol的暂不涉及。任何MySQL客户端（CLI、GUI、MySQL驱动）与MySQL服务器通信，都需要使用这个协议。这个协议包含一系列的命令消息（COM）和响应消息（Response）、编解码方式和交互流程。

上图展示了绝大多数协议消息的交互过程：对于DQL，服务器会返回FIELD_COUNT（列数）、FIELD（列的描述信息，如类型等）、ROW（每一行数据的值）、EOF（结束标志）；而对于DML，只需要返回OK或者ERR，通知客户端命令执行成功或失败。

经过之前的分析，我们可以把范围缩小到OK_Packet这条响应消息上，这条消息由服务器发送给客户端，表示一条命令的成功执行。也就是说，在插入数据成功后，MySQL服务器会发送OK_Packet给Proxy，后者又会把这条消息发送给客户端。消息格式如下：

这个表格看起来有点抽象，我们可以先用Wireshark抓个真实包看看，解析出来会直观一些：

做协议开发永远离不开Wireshark，后面拓海会手把手教你使用Wireshark进行网络抓包。真实的数据看起来就简单明了一些了，有包长度、包序号、影响行数、最后插入id、服务器状态等信息。我们找一个字段，来说明其编解码方式。例如last_insert_id，它的类型是int<lenenc>，值为1083。

MySQL协议里存储数据的方式是小端字节序，这是什么意思呢？比如一个值0x1234，采用大端字节序的存储方式就是0x1234，而小端方式则是0x3412。MySQL采用这样的字节序很不友好，对于一个通信协议，应该使用网络字节序传输数据，而不是机器字节序。

回到协议，int<lenenc>是变长编码的整数类型，不同范围的数值使用不同的长度来编码：

由上可知，1083这个值应该是0xfc 加上2个字节来表示：

1083 = 0x043b，小端字节序就是0x3b04。有了这些基础，我们就可以通过抓包来分析产生bug的根本原因了。

Bug最终定位

以下就是当时抓到的包，看起来非常的“正常”，插入一条数据，返回一条成功的响应，Wireshark也没有解析出错。看现象就是客户端停止了插入数据。

经过多次试验，最后一条INSERT总是卡在t_order_item这个表上，它与t_order表有什么本质区别呢？了解Sharding-Sphere-Example的同学对这两个表应该很熟悉，t_order使用的是雪花算法生成的分布式主键，值很大，而t_order_item使用的是MySQL自增主键。为什么主键值小的表会卡住？

又经过一系列调查，发现t_order_item表也不是每次都卡住，这个表有两个分片，在其中一个分片上永远没问题，而另一个分片上只要插入数据就会卡。这两个表又有什么区别呢？其实，由于分片的不均匀，一个表的数据量多，另一个数据量少，除此之外没什么不同。数据量多的表大概6万多条数据。

在拓海百思不得其解的时候，亮神和赵帅看出了些端倪：

最后一条OK_Packet的Last INSERT ID值太大了，一个表不可能有这么多数据。通过观察发现，表的数据量已经大于65535，应该使用3个字节存储

然而程序里却使用了四个字节。四个字节的编码在协议里是不存在的，这必然导致客户端jdbc解析出错。至于为什么wireshark没有解析出错，那一定是因为它的解析逻辑错了。

使用Wireshark分析MySQL协议

Wireshark可以理解为是一个带图形界面的tcpdump，同时集成了非常多的协议解析插件，可以帮助我们方便的抓取和分析MySQL协议。需要注意的是，Wireshark只能抓网络协议包，但MySQL协议还有其他通信方式，如Shared memory，Named pipes，这些是抓不到的，最好不要开这些参数。

Linux命令行环境下：可以先用tcpdump抓包，然后将包发送到本地，使用Wireshark解析。命令如下：

tcpdump -i any port 3307 -w test.pcap

any: 表示所有网络接口。

port: tcp端口，Proxy的默认端口是3307，如果你关心MySQL的包，就改为3306。

pcap: 一种通用的数据流格式，Wireshark可以直接打开。

用Wireshark打开test.pcap，你会发现除了MySQL协议，还显示很多TCP协议的ACK消息：

在过滤器中输入mysql，进行过滤即可：

Windows环境下：直接使用Wireshark抓包，一边抓包一边解析。本地的测试环境往往会同时运行客户端、Proxy和MySQL服务器，它们的通信在同一台机器上是不走网卡的，然而windows系统又没有提供本地回环网络的接口，所以这种情况下是什么也抓不到的。

为了解决这个问题，我们需要把Wireshark在Windows系统上默认的抓包工具WinPcap替换为Npcap，在这里下载：https://nmap.org/npcap/#download

安装前先在Wireshark的安装目录下卸载WinPcap。安装时勾选如下选项：

安装完成再次启动Wireshark时，就会看到在网络接口列表中，多了一项Npcap Loopback adapter，这个就是来抓本地回环包的网络接口了：

小结

Sharding-Sphere自2016开源以来，不断精进、不断发展，被越来越多的企业和个人认可：在Github上收获5000+的star，1900+forks，60+的各大公司企业使用它，为Sharding-Sphere提供了重要的成功案例。此外，越来越多的企业伙伴和个人也加入到Sharding-Sphere的开源项目中，为它的成长和发展贡献了巨大力量。

我们从未停息过脚步，聆听社区伙伴的需求和建议，不断开发新的强大功能，不断使其健壮可靠！开源不易, 我们却愿向着最终的目标，步履不停！那么，正在阅读的你，是否可以助我们一臂之力呢？分享、转发、使用、交流，以及加入我们，都是对我们最大的鼓励！

Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成。他们均提供标准化的数据分片、读写分离、柔性事务和数据治理功能，适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
亦步亦趋，开源不易，您对我们最大支持，就是在github上留下一个star。

项目地址：

​​​​https://github.com/sharding-sphere/sharding-sphere/​​​​

https://gitee.com/sharding-sphere/sharding-sphere/
更多信息请浏览官网：
​​​http://shardingsphere.io/​​