问题起因:用benchmarksql_for_mysql对原生MyCat-1.6.1和DBLE-2.17.07版做性能测试对比，发现DBLE性能只到原生版MyCat的70%左右。
问题分析过程:分析过程主要有以下内容：包括现象，收集数据，分析猜测原因，验证猜测的方式来进行。
1.分析瓶颈
1.1先对两者进行一个CPU占用的堆栈分析
通过对CPU火焰图的比较，发现DBLE用在纯排序上的CPU占用在15%以上，而MyCat在排序上没有看到明显的CPU占用。（复盘时的思考：这里有明显的可疑之处，应当及早观察两者是否公平）
1.2首先猜测可能的原因
a由于MyCat对以下这条用例实现有bug：具体方式是直接原句下发SQL到节点，收到各个节点的结果后直接做加法；而DBLE则是改写未select distinct s_i_id 收集全部结果集，然后在中间件做去重和统计的工作。所以两者在这个case上的对比是不公平的。
b排序本身算法选择的问题
1.3对猜测原因的验证
a 去除有bug的case，并未看到性能有提升，而且考虑这条用例在所有用例出现的概率只有4%，涉及到的数据也不多，所以应该不是性能问题的主因。
b 去除有排序的case，看到两者性能接近，确定是排序的问题。
2.猜测原因
2.1猜测一：源码实现原因
2.1.1猜测描述
梳理DBLE源码排序逻辑的实现细节，是多路归并的排序，理论上是最优选择。
实际上具体的实现上有可优化的空间，如下图，N个数的K路排序的初始化值理论最优复杂度是O(N)，而这里变成了O(Nlogk2)。
2.1.2验证猜测
为了快速将排序的因素排除，将cmp函数直接返回1再次做测试。结果提升了10%的性能，所以虽然cmp是有性能问题，但导致性能如此大还有其他原因。（复盘：新版本已优化此处10%的性能差异）
2.2猜测二：回到排序SQL
查看B-SQL源码，有3个排序SQL，其中有2个排序SQL的排序不在select中，这本来应该引发MyCat的bug的，但我们在返回集合抓包中都没有发现。再仔细阅读源码，原来B-SQL通过hard code的方式使得压力永远跑不到这两个代码路径上，这样我们又排除了2个干扰因素，问题集中到剩下的哪个排序上了。
将排序除去，64数据量，64并发，DBLE的性能是MyCat的96%。
证明确实和排序有关。
3.分析多并发压力排序性能的原因
3.1猜测排序算法在特殊场景下的适用性
3.1.1猜测描述
由于MyCat排序采用的是timsort，时间复杂度的可能最优是O(n)。
而DBLE的多路归并排序在B-SQL这个场景下时间复杂度最差清空是O(n*(k-1))。
猜测timsort排序在B-SQL多并发场景下可能会优于多路归并。
3.1.2验证猜测
用B-SQL压测并统计函数调用次数
结论：
在B-SQL场景下：
两者平均每个排序调用的cmp函数的次数并没有发生明显的异化
每个排序cmp次数虽然没有大的差异，但总的调用次数却相差很大，DBLE大约是MyCat的5倍
4.分析DBLE排序时cmp函数次数调用多的原因
问题集中在了为什么DBLE会有更多次的比较函数调用。
4.1验证压力下发的SQL是否与cmp函数调用相符，是否下发的SQL就不公平
4.1.1收集数据
用抓包的方式分别抓B-SQL发给MyCat和DBLE的包，结果发现DBLE的所有SQL中，排序这条SQL的发生次数是MyCat的10倍左右。
再次用yourkit查看调用次数喝CPU分布验证，发现调用次数确实符合抓包的结论，CPU分布也是DBLE分了大量的时间用于排序，而MyCat对排序的分片几乎可以忽略。这也与最开始的火焰图结论一样。
用wireshark分析DBLE抓包结果，发现某些连接执行一段时间之后，大量的重复出现排序+delete的query请求，直到压力结束，举例如下图：
4.1.2分析原因
分析B-SQL源码这里发现只有delete的数据为0才会引发死循环。
4.1.3验证测试
在引发死循环的原因找到之前，先修改代码验证测试。无论result是否是0，都设置newOrderRemoved=true，使得B-SQL跳出死循环。
验证测试，DBLE性能终于符合预期，变为MyCat的105%。
至此，B-SQL有排序引发DBLE性能下降的原因找到了，某种场景下B-SQL对DBLE执行delete，影响行数为0，导致此时会有死循环，发送了大量排序请求，严重降低了DBLE性能，并且并发压力越大越容易出现，但也有一定几率不会触发。
5.分析哪种场景下delete行数为0
5.1隔离级别测试
在MySQL上做了一个实验：
也就是说，在并发清空下确实有可能出现死循环。
5.2分析为什么只有在DBLE上有这个问题而在MyCat上没有这个问题
原因是DBLE和MyCat的默认隔离级别都是REPEATED_READ，但MyCat的实现有bug，除非客户端显式使用set语句，MyCat后端连接使用的隔离级别都是下属结点上的默认隔离级别；
而DBLE会在获取后端连接后同步上下文，使得session级别的隔离级别和DBLE配置相同。而后端的四个结点中除了1台是REPEATED_READ，其他三个结点都是READ_COMMITTED。这样同样的并发条件，DBLE100%会触发，而MyCat只有25%的概率触发。
5.3验证测试
将DBLE的配置加上<property name="txlsolation">2</property>（默认是3）与默认做对比：
性能比是1：0.75，符合期望，性能原因全部找到。
6.吐槽
最后吐槽一下B-SQL，找了官方的B-SQL4.1版和5.0版，4.1版并未对此情况做任何改进，仍有可能陷入死循环影响测试。
而5.0的对应代码处有这么一段注释，不知道PGSQL是否这里真的会触发异常，但MySQL并不会触发异常，仍有可能陷入死循环。
7.性能原因回顾
1.cmp函数时候初始化值的问题，影响部分性能，非主要性能瓶颈，新版本已改进。
2.同时触发了MyCat和B-SQL的两个bug，导致测试的性能数据负负得正；
- MyCat bug：配置的隔离级别不生效问题
- B-SQL bug：RR隔离级别下，delete死循环问题
需要将MySQL结点都改为READ_COMMITED，再将配置改为<property name="txlsolation">2</property>，避开上述的bug。
8.收获
1.测试环境的搭建无论是配置参数还是各个结点的状态都要同步，保证公平。
2.性能分析工具的使用。
3.性能测试可能一次的结果具有偶然性，需要多次验证。
4.当有矛盾的结论时，可能就快接近问题的真相了，需要持续关注。