在千万级别的数据量下，读写分离和分库分表已经成为解决单表瓶颈的标准做法。ShardingSphere-JDBC 把分片逻辑放在应用程序中，省去了一个网络跳；而 MyCAT 则采用独立的代理方式，对业务透明但是多了一次转发。
压测环境为4C8G的MySQL 8.0数据库，千兆网卡，4个分片，单表数据量达到千万级别，使用Sysbench进行只读和读写混合测试。
- 主键单分片查询：ShardingSphere-JDBC约为1.2毫秒，ShardingSphere-Proxy约为3.8毫秒，MyCAT约为5.1毫秒
- 跨分片聚合 count：ShardingSphere 并行归并 15ms 左右，MyCAT 串行代理聚合 38ms 左右
- 批量插入1000条数据时，ShardingSphere-JDBC耗时120ms，Proxy耗时340ms，MyCAT耗时890ms
- 只读场景下，ShardingSphere-JDBC可以支持到85%-90%，而MyCAT只能达到60%-70%
延迟差主要是由代理层序列化和线程模型造成的。MyCAT 在简单的读写情况下表现良好，在高并发跨分片、复杂的JOIN以及子查询等复杂场景下，其路由和归并效率下降得更快一些；而 ShardingSphere 的 JDBC 模式将解析、路由以及结果合并都放在了本地进行，因此它的响应时间要短很多，但是用 Proxy 模式来换取多语言透明访问的话，则会产生接近 MyCAT 代理层的开销。
MyCAT 的收敛性能更好一些：后端连接通过代理进行统一池化，可以支持多种语言和多种服务共用一个分片层；而 ShardingSphere-JDBC 的连接数量会随着应用程序实例数的增加而呈线性增长，只有采用 Proxy 模式才能弥补其收敛能力的不足。在 SQL 兼容性方面，ShardingSphere 对于子查询、跨分片 JOIN 以及窗口函数等复杂语句的支持更加完善一些，但是 MyCAT 仍然需要依靠应用层来兜底。
追求低延迟、高吞吐和Java技术栈深度集成的情况下，ShardingSphere-JDBC属于压测数据中最好的选择之一，适用于对响应时间非常敏感的核心交易链路；而如果需要异构语言接入以及运维方面统一管理分片和读写分离的话，则应该使用ShardingSphere-Proxy或者MyCAT，其中MyCAT虽然配置简单但是社区更新速度较慢，复杂查询和高并发性能上限较低。