- ⽐较常⻅的分库分表中间件包括：Cobar、TDDL、Atlas、Sharding-jdbc、Mycat
【Cobar】
- 阿⾥ b2b 团队开发和开源的，属于 proxy 层⽅案，就是介于应⽤服务器和数据库服务器之间。
- 应⽤程序通过 JDBC 驱动访问 Cobar 集群，Cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执⾏。
- 早些年还可以⽤，但是最近⼏年都没更新了，基本没啥⼈⽤，差不多算是被抛弃的状态吧。⽽且不⽀持读写分离、存储过程、跨库 join 和分⻚等操作。
【TDDL】
- 淘宝团队开发的，属于 client 层⽅案。⽀持基本的 crud 语法和读写分离，但不⽀持 join、多表查询等语法。
- ⽬前使⽤的也不多，因为还依赖淘宝的 diamond 配置管理系统。
【Atlas】
- 360 开源的，属于 proxy 层⽅案，以前是有⼀些公司在⽤的，但是确实有⼀个很⼤的问题就是社区最新的维护都在 5 年前了。所以，现在⽤的公司基本也很少了。
【Sharding-jdbc】
- 当当开源的，属于 client 层⽅案，⽬前已经更名为 ShardingSphere （后⽂所提到的Sharding-jdbc ，等同于 ShardingSphere ）。
- 确实之前⽤的还⽐较多⼀些，因为 SQL 语法⽀持也⽐较多，没有太多限制，⽽且截⾄ 2019.4，已经推出到了 4.0.0-RC1 版本，⽀持分库分表、读写分离、分布式 id ⽣成、柔性事务（最⼤努⼒送达型事务、TCC 事务）。
- ⽽且确实之前使⽤的公司会⽐较多⼀些，⽬前社区也还⼀直在开发和维护，还算是⽐较活跃，个⼈认为算是⼀个现在也可以选择的⽅案。
【Mycat】
- 基于 Cobar 改造的，属于 proxy 层⽅案，⽀持的功能⾮常完善，⽽且⽬前应该是⾮常⽕的⽽且不断流⾏的数据库中间件，社区很活跃，也有⼀些公司开始在⽤了。
- 但是确实相⽐于 Sharding-jdbc 来说，年轻⼀些，经历的锤炼少⼀些。
【总结】
- 综上，现在其实建议考量的，就是 Sharding-jdbc 和 Mycat，这两个都可以去考虑使⽤。
- Sharding-jdbc 这种 client 层⽅案的优点在于不⽤部署，运维成本低，不需要代理层的⼆次转发请求，性能很⾼，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 Sharding-jdbc 的依赖；
- Mycat 这种 proxy 层⽅案的缺点在于需要部署，⾃⼰运维⼀套中间件，运维成本⾼，但是好处在于对于各个项⽬是透明的，如果遇到升级之类的都是⾃⼰中间件那⾥搞就⾏了。
- 通常来说，这两个⽅案其实都可以选⽤，但是我个⼈建议中⼩型公司选⽤ Sharding-jdbc，client层⽅案轻便，⽽且维护成本低，不需要额外增派⼈⼿，⽽且中⼩型公司系统复杂度会低⼀些，项⽬也没那么多；但是中⼤型公司最好还是选⽤ Mycat 这类 proxy 层⽅案，因为可能⼤公司系统和项⽬⾮常多，团队很⼤，⼈员充⾜，那么最好是专⻔弄个⼈来研究和维护 Mycat，然后⼤量项⽬直接透明使⽤即可。
