作者
骆俊武
这篇文章记录了给Apache顶级项目-分库分表中间件ShardingSphere提交Bug的历程。
说实话，这是一次比较曲折的Bug跟踪之旅。10月28日，我们在GitHub上提交issue，中途因为官方开发者的主观臆断被Close了两次，直到11月20日才被认定成Bug并发出修复版本，历时20多天。
本文将还原该Bug的分析过程，将有价值的经验和技术点进行提炼。通过本文，你将收获到：
1、疑难问题的排查思路2、数据库中间件ShardingProxy的原理3、MySQL预编译的流程和交互协议4、Wireshark抓包分析MySQL的奇淫技巧
问题描述
这个Bug来源于我的公号读者，他替公司预研ShardingProxy（属于ShardingSphere的子产品，可用作分库分表，后文会详细介绍）。他按照官方文档写了一个很简单的demo，但是运行后无法查询出数据。
下面是他遇到问题后发给我的信息，希望我能帮忙一起定位下原因。
截图中的doc详细记录了ShardingProxy的配置、调试分析日志、以及问题的具体现象。
为了方便大家理解，我重新描述下这个Demo的业务逻辑以及问题表象。
1.Demo的业务逻辑说明
这个Demo很简单，主要为了跑通ShardingProxy的分库分表功能。程序用SpringBoot+MyBatis实现了一个单表的查询逻辑，然后用这张表的一个long类型字段作为分区键，并通过ShardingProxy进行了分表。
下面是那张数据表的详细定义，共16个字段，大家