[MyCAT]于无声处听惊雷

说到分表分库，现在几乎已经是业内的标准了。
比如阿里的PolarDB-X，腾讯的TDSQL，华为的ddm等。
分表分库的好处是，在不入侵业务的前提下，解决大表导致的性能问题，目前分表分库还或多或少存在一些局限性，导致使用者在一开始就要考虑到这些问题，并进行合理规划。

shardingsphere

之前看过一段时间的shardingsphere，源码包的架构如下：

看过一些它的源码，源码写的较为层次分明，又合理利用了SPI技术解耦，但是缺点是太过复杂且底层存在很多bug难以简单修复，因为还在大迭代导致源码结构一变再变不太好维护，社区虽活跃但提出问题很难得到正反馈，笔者提过一些问题都被主创团队忽视掉了。

mycat

这个产品是接触过最早的开源的分表分库的组件，活跃于2016年，最近社区几乎死亡，只有偶尔还有一些小的更新，进群需要给钱，问问题也需要给钱，社区生态糟糕。源码包架构如下图所示：

看了它的部分源码，逻辑较为简单。以解析为例，shardingsphere用了antlr4插件进行构建语法树进行解析，每次sql进来都需要构建语法树，在测试过程中发现极大消耗CPU，而mycat这块的源码如下图所示：



这就像是普通程序员写的普通逻辑代码：它的解析流程是，跳过无意义的字节，从第一个有意义的字节开始判断这是个什么语句，针对相应类型进入相应实现处理SQL。

于无声处听惊雷

尺有所短，寸有所长。

shardingsphere拥有更好的生态圈，而且现在已经是apache下面的顶级项目，活跃的社区，更好的代码结构决定了它会走的更远，但是由于其结构复杂并不一定便于各家公司掌控，在不使用预编译时有极大性能问题，使用预编译时有较多bug发现；

mycat基本已经宣布死亡，主创团队也已经分崩离析，但是其简单性导致其成为华为等公司二次开发的首选。

辩证的去看，如何结合两者的优势，成为下一步工作的重点。