由于我们胆子不够大，哈哈，所以不敢直接上分布式数据库TiDB 什么的，所以还是基于mysql的分布式集群架构，这样就会需要数据库中间件来处理数据层的诸多因分布式而带来的功能需求。
DRDS品牌全面升级至云原生分布式数据库PolarDB-X
PolarDB-X是由阿里巴巴自主研发的云原生分布式数据库，融合分布式SQL引擎DRDS与分布式自研存储X-DB，基于云原生一体化架构设计，可支撑千万级并发规模及百PB级海量存储。专注解决海量数据存储、超高并发吞吐、大表瓶颈以及复杂计算效率等数据库瓶颈问题，历经各届天猫双十一及阿里云各行业客户业务的考验，助力企业加速完成业务数字化转型 。
-
生命周期管理
-
实例创建、重启、释放
-
数据库创建、删除
-
数据白屏化操作
-
-
容量管理
-
水平拆分、垂直拆分
-
读写分离
-
只读实例
-
弹性变配
-
平滑扩容、热点扩容
-
拆分变更
-
-
安全与审计
-
VPC
-
IP白名单
-
账号与权限管理
-
SQL审计与分析
-
-
容灾管理
-
备份恢复
-
SQL闪回
-
表回收站
-
多可用区实例容灾部署
-
-
监控告警
-
分层监控
-
云监控接入与关键指标报警管理
-
-
数据生态
-
DTS数据迁移、同步、订阅
-
数据集成
-
DMS数据管理
-
QuickBi集成
-
搜索OpenSearch、Elasticsearch
-
大数据计算与数据仓库
-
2013年阿里的Cobar在社区使用过程中发现存在一些比较严重的问题，及其使用限制，经过Mycat发起人第一次改良，第一代改良版——Mycat诞生。 Mycat开源以后，一些Cobar的用户参与了Mycat的开发，最终Mycat发展成为一个由众多软件公司的实力派架构师和资深开发人员维护的社区型开源软件。
关键特性
-
支持SQL92标准
-
支持MySQL、Oracle、DB2、SQL Server、PostgreSQL等DB的常见SQL语法
-
遵守Mysql原生协议，跨语言，跨平台，跨数据库的通用中间件代理。
-
基于心跳的自动故障切换，支持读写分离，支持MySQL主从，以及galera cluster集群。
-
支持Galera for MySQL集群，Percona Cluster或者MariaDB cluster
-
基于Nio实现，有效管理线程，解决高并发问题。
-
支持数据的多片自动路由与聚合，支持sum,count,max等常用的聚合函数,支持跨库分页。
-
支持单库内部任意join，支持跨库2表join，甚至基于caltlet的多表join。
-
支持通过全局表，ER关系的分片策略，实现了高效的多表join查询。
-
支持多租户方案。
-
支持分布式事务（弱xa）。
-
支持XA分布式事务（1.6.5）。
-
支持全局序列号，解决分布式下的主键生成问题。
-
分片规则丰富，插件化开发，易于扩展。
-
强大的web，命令行监控。
-
支持前端作为MySQL通用代理，后端JDBC方式支持Oracle、DB2、SQL Server 、 mongodb 、巨杉。
-
支持密码加密
-
支持服务降级
-
支持IP白名单
-
支持SQL黑名单、sql注入攻击拦截
-
支持prepare预编译指令（1.6）
-
支持非堆内存(Direct Memory)聚合计算（1.6）
-
支持PostgreSQL的native协议（1.6）
-
支持mysql和oracle存储过程，out参数、多结果集返回（1.6）
-
支持zookeeper协调主从切换、zk序列、配置zk化（1.6）
-
支持库内分表（1.6）
-
集群基于ZooKeeper管理，在线升级，扩容，智能优化，大数据处理（2.0开发版）。
Apache 顶级项目
Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款相互独立，却又能够混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
核心功能
-
数据分片
-
分布式事务
-
读写分离
-
分布式治理
-
弹性伸缩
-
数据加密
-
影子库压测
-
可插拔架构
-
测试引擎
实际上除了Mycat 和 sharding-sphere 还有其他几个数据库中间件，但由于其他一些 “年久失修” 不再维护，或功能不够丰富与完善就不纳入我们的对比范围了。
目前我们主要对比 Mycat 和 Apache ShardingSphere
以 MySQL 为例，分库分表从阶段应该拆分为分表、分库，一般来说是先进行分表，分表的原动力在于 MySQL 单表性能问题，相信大家都听说过类似这样的话，据说 MySQL 单表数据量超过 N 千万、或者表 Size 大于 N十G 性能就不行了。这个说法背后的逻辑是数据量超过一定大小，B+Tree 索引的高度就会增加，而每增加一层高度，整个索引扫描就会多一次 IO 。整个逻辑有一定道理，而从笔者的经验来看，其实更关键在于应用本身的使用，如果多数是索引命中率很高的点查或者小范围查，其实这个上限还很高，我们维护的系统里超过10亿级的表很常见。但正是由于业务的不可控，所以大家往往采取比较保守的策略，这就是分表的原因。
功能对比
| Mycat | Sharding-JDBC | Sharding-Proxy | Sharding-Sidecar | Sharding-Sidecar |
|---|---|---|---|---|
| 官方网站 | 官方网站 | 官方网站 | 官方网站 | 官方网站 |
| 源码地址 | GitHub | GitHub | GitHub | GitHub |
| 官方文档 | Mycat 权威指南 | 官方文档 | 官方文档 | 官方文档 |
| 开发语言 | Java | Java | Java | Java |
| 开源协议 | GPL-2.0/GPL-3.0 | Apache-2.0 | Apache-2.0 | Apache-2.0 |
| 数据库 | MySQL Oracle SQL Server PostgreSQL DB2 MongoDB SequoiaDB | MySQL Oracle SQLServer PostgreSQL 任何遵循 SQL92 标准的数据库 | MySQL PostgreSQL | MySQL/PostgreSQL |
| 连接数 | 低 | 高 | 低 | 高 |
| 应用语言 | 任意 | Java | 任意 | 任意 |
| 代码入侵 | 无 | 需要修改代码 | 无 | 无 |
| 性能 | 损耗略高 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 否 | 是 | 否 | 是 |
| 静态入口 | 有 | 无 | 有 | 无 |
| 管理控制台 | Mycat-web | Sharding-UI | Sharding-UI | Sharding-UI |
| 分库分表 | 单库多表/多库单表 | ✔️ | ✔️ | ✔️ |
| 多租户方案 | ✔️ | -- | -- | -- |
| 读写分离 | ✔️ | ✔️ | ✔️ | ✔️ |
| 分片策略定制化 | ✔️ | ✔️ | ✔️ | ✔️ |
| 分布式主键 | ✔️ | ✔️ | ✔️ | ✔️ |
| 标准化事务接口 | ✔️ | ✔️ | ✔️ | ✔️ |
| XA强一致事务 | ✔️ | ✔️ | ✔️ | ✔️ |
| 柔性事务 | -- | ✔️ | ✔️ | ✔️ |
| 配置动态化 | 开发中 | ✔️ | ✔️ | ✔️ |
| 编排治理 | 开发中 | ✔️ | ✔️ | ✔️ |
| 数据脱敏 | -- | ✔️ | ✔️ | ✔️ |
| 可视化链路追踪 | -- | ✔️ | ✔️ | ✔️ |
| 弹性伸缩 | 开发中 | 开发中 | 开发中 | 开发中 |
| 多节点操作 | 分页 去重 排序 分组 聚合 | 分页 去重 排序 分组 聚合 | 分页 去重 排序 分组 聚合 | 分页 去重 排序 分组 聚合 |
| 跨库关联 | 跨库 2 表 Join ER Join 基于 caltlet 的多表 Join | -- | -- | -- |
| IP 白名单 | ✔️ | -- | -- | -- |
| SQL 黑名单 | ✔️ | -- | -- | -- |
| 存储过程 | ✔️ | -- | -- | -- |