一般对于业务记录类随时间会不断增加的数据，当数据量增加到一定量（一般认为整型值为主的表达到千万级，字符串为主的表达到五百万）的时候，性能将遇到瓶颈，同时调整表结构也会变得非常困难。为了避免生产遇到这样的问题，在做系统设计时需要预估可能产生的数据量：预估记录主体个数*预估记录主体产生的记录数（e.g.用户订单表预估数据量=预估用户数*单用户产生订单数），预估达到一定量时，就不得不考虑分库分表了，目前国内比较成熟的开源数据库中间件有sharding-jdbc、mycat；而drds是阿里云最近推出的商业产品，考虑到大部分公司都在使用阿里云，做一个全家桶，也是一个不错的选择。接下来将对这三款产品的优缺点及适用场景做以介绍。
可以看出sharding-jdbc作为一个组件集成在应用内，而mycat则作为一个独立的应用需要单独部署，drds则是阿里云的一个独立产品，不过需要结合rds一起使用。从架构上看sharding-jdbc更符合分布式架构的设计，直连数据库，没有中间应用，理论性能是最高的（实际性能需要结合具体的代码实现，理论性能可以理解为上限，通过不断优化代码实现，逐渐接近理论性能）。同时缺点也很明显，由于作为组件存在，需要集成在应用内，意味着作为使用方，必须要集成到代码里，使得开发成本相对较高；另一方面，由于需要集成在应用内，使得需要针对不同语言（java、C、PHP……）有不同的实现（事实上sharding-jdbc目前只支持java），这样组件本身的维护成本也会很高。最终将应用场景限定在由java开发的应用这一种场景下。
sharding-jdbc后续发展为Sharding-Sphere，包含sharding-jdbc、Sharding-Proxy、Sharding-Sidecar
来源：https://github.com/sharding-sphere/sharding-sphere
mycat是支持SQL92标准，遵守Mysql原生协议，跨语言，跨平台，跨数据库的通用中间件代理。作为对比可以参考上表中的Sharding-Proxy，需要单独部署，由于遵守Mysql原生协议，应用时不需要特殊处理，和使用MySQL是一样的，所以应用场景不受限制；但是mycat不支持二维路由，仅支持单库多表或多库单表，同时由于自定义连接池，这样就会存在mycat自身维护一个连接池，MySQL也有一个连接池，任何一个连接池上限都会成为性能的瓶颈，而mycat的连接池设计也略显粗暴，当请求链接数大于设置连接池上限时直接抛出异常，因此在配置mycat连接池的大小是，需要结合场景做合理设置。总的来说，mycat以逻辑表的形式屏蔽掉应用处理分库分表的复杂逻辑，遵守Mysql原生协议，跨语言，跨平台，有着更为通用的应用场景。
DRDS 兼容 MySQL 协议和语法，支持分库分表、平滑扩容、服务升降配、透明读写分离和分布式事务等特性，具备分布式数据库全生命周期的运维管控能力。可以看成mycat的商业化产品，也就是mycat所有的优点它都有，而且作为一个商业化产品使用上更为简单透明，功能也更为丰富；如果不差钱而且正准备对数据做重构，那么drds是一个不错的选择，之所以说准备做数据重构时考虑用drds，是因为drds不是一个简单的做sharding路由，即使原来使用的是rds，也无法通过drds做路由，唯一的办法新建drds实例，定义路由规则（drds支持二维路由），导入历史数据，然后就可以开心的使用drds了。
然后做个简单总结
————————————————
版权声明：本文为CSDN博主「jornada_」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jornada_/article/details/82947677