强烈推荐TiDB，这是未来大中型公司的数据库，一定的
NewSQL
优点：
- 传统数据库面向磁盘设计，基于内存的存储管理及并发控制，NewSQL数据库那般高效利用
- 中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作，效率相比较低
- 分布式事务相比于XA进行了优化，性能更高
- 基于paxos（或Raft）协议的多副本，实现了真正的高可用、高可靠
- 天生支持数据分片，数据的迁移、扩容都是自动化的，大大减轻了DBA的工作，同时对应用透明，无需在SQL指定分库分表键
- 最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。
缺点：
- NewSQL数据库一般并不支持存储过程、外键等功能（新版本已经可以支持普通视图）
- 往往选择兼容MySQL或者PostgreSQL协议，所以SQL支持仅局限于这两种
对比
| mycat | sharding-JDBC | Sharding-Proxy | Sharding-Sidecar | TiDB | |
|---|---|---|---|---|---|
| 官方网站 | 官方网站 | 官方网站 | 官方网站 | 官方网站 | 官方网站 |
| 源码地址 | GitHub | GitHub | GitHub | GitHub | GitHub |
| 官方文档 | Mycat 权威指南 | 官方文档 | 官方文档 | 官方文档 | 官方文档 |
| github的Star数量 | 8.5k | 12.2k | 12.2k | 12.2k | 25.4k |
| 开发语言 | Java | Java | Java | Java | Go |
| 开源协议 | GPL-2.0/GPL-3.0 | Apache-2.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 | 高度兼容MySQL |
| 连接消耗数 | 低 | 高 | 低 | 高 | |
| 应用语言 | 任意 | Java | 任意 | 任意 | 任意 |
| 代码入侵 | 无 | 需要修改代码 | 无 | 无 | 几乎不需要修改 |
| 性能 | 损耗略高 | 损耗低 | 损耗略高 | 损耗低 | 官方测试报告 |
| 无中心化 | 否 | 是 | 否 | 是 | 无 |
| 静态入口 | 有 | 无 | 有 | 无 | – |
| 管理控制台 | Mycat-web | Sharding-UI | Sharding-UI | Sharding-UI | TiDB Dashboard UI（实验特性阶段） |
| 分库分表 | 单库多表/多库单表 | ✔️ | ✔️ | ✔️ | 不需要，分布式数据库，天生牛逼 |
| 多租户方案 | ✔️ | – | – | – | |
| 读写分离 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 分片策略定制化 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 分布式主键 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 标准化事务接口 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| XA强一致事务 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 柔性事务 | – | ✔️ | ✔️ | ✔️ | ✔️ |
| 配置动态化 | 开发中 | ✔️ | ✔️ | ✔️ | 实验性阶段 |
| 编排治理 | 开发中 | ✔️ | ✔️ | ✔️ | |
| 数据脱敏 | – | ✔️ | ✔️ | ✔️ | |
| 可视化链路追踪 | – | ✔️ | ✔️ | ✔️ | |
| 弹性伸缩 | 开发中 | 开发中 | 开发中 | 开发中 | ✔️ |
| 多节点操作 | 分页 去重 排序 分组 聚合 | 分页 去重 排序 分组 聚合 | 分页 去重 排序 分组 聚合 | 分页 去重 排序 分组 聚合 | ✔️ |
| 跨库关联 | 支持单库内部任意join，支持跨库2表join，甚至基于caltlet的多表join | – | – | – | ✔️ |
| IP 白名单 | ✔️ | – | – | – | ✔️ |
| SQL 黑名单 | ✔️ | – | – | – | |
| 存储过程 | ✔️ | – | – | – | – |
| 密码加密 | ✔️ | ✔️ | |||
| 服务降级 | ✔️ | ||||
| 运维实施难度 | 一般 | 简单 | 简单 | 初步上手，概念多，有一定成本 |
总结
如果看完以上内容，您还不知道选哪种模式，那么结合以下几个问题，先思考下NewSQL数据库解决的点对于自身是不是真正的痛点：
- 强一致事务是否必须在数据库层解决？
- 数据的增长速度是否不可预估的？
- 扩容的频率是否已超出了自身运维能力？
- 相比响应时间更看重吞吐？
- 是否必须做到对应用完全透明？
- 是否有熟悉NewSQL数据库的DBA团队？
如果以上有2到3个是肯定的，那么你可以考虑用NewSQL数据库了，虽然前期可能需要一定的学习成本，但它是数据库的发展方向，未来收益也会更高，尤其是互联网行业，随着数据量的突飞猛进，分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。
如果你还未做出抉择，不妨再想想下面几个问题：
- 最终一致性是否可以满足实际场景？
- 数据未来几年的总量是否可以预估？
- 扩容、DDL等操作是否有系统维护窗口？
- 对响应时间是否比吞吐更敏感？
- 是否需要兼容已有的关系数据库系统？
- 是否已有传统数据库DBA人才的积累？
- 是否可容忍分库分表对应用的侵入？
如果这些问题有多数是肯定的，那还是分库分表吧。在软件领域很少有完美的解决方案，NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案，它最大程度复用传统关系数据库生态，通过中间件也可以满足分库分表后的绝大多数功能，定制化能力更强。
