MyCat 属于服务器端的数据库中间件，而 Sharding-jdbc 是一个 本地 数据库中间件框架，从设计理念上看确实有一定的相似性。 主要流程都是SQL解析 -> SQL路由 ->SQL改写 -> SQL执行->结果归并，但架构设计上是不同的。MyCat 是基于Proxy，它复写了MyCat协议，将MyCat server伪装成一个 MyCat 数据库；而Sharding-jdbc 是基于 jdbc 的扩展是以jar包的形式提供轻量级服务的，使用MyCat时不需要改代码，而使用Sharding-jdbc时需要修改代码，对应用入侵性比较强。
MyCat是支持SQL92标准，遵守Mysql原生协议，跨语言，跨平台，跨数据库的通用中间件代理。由于遵守Mysql原生协议，应用时不需要特殊处理，和使用MySQL是一样的，所以应用场景不受限制；但是mycat不支持二维路由，仅支持单库多表或多库单表，同时由于自定义连接池，这样就会存在mycat自身维护一个连接池，MySQL也有一个连接池，任何一个连接池上限都会成为性能的瓶颈，而mycat的连接池设计也略显粗暴，当请求链接数大于设置连接池上限时直接抛出异常，因此在配置mycat连接池的大小是，需要结合场景做合理设置。总的来说，mycat以逻辑表的形式屏蔽掉应用处理分库分表的复杂逻辑，遵守Mysql原生协议，跨语言，跨平台，有着更为通用的应用场景。
从架构上看Sharding-jdbc更符合分布式架构的设计，直连数据库，没有中间应用，理论性能是最高的（实际性能需要结合具体的代码实现，理论性能可以理解为上限，通过不断优化代码实现，逐渐接近理论性能）。同时缺点也很明显，由于作为组件存在，需要集成在应用内，意味着作为使用方，必须要集成到代码里，使得开发成本相对较高。
以下为Mycat 和 ShardingSphere（包括 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar 3 款产品）功能的比较：
