背景：
0 目前存在20张表单表的数据量在百万、千万级别，最大的是2千万级别.
1 业务扩充，后期大概率是重点业务，原本8个城市，22年开始扩充到三十余个城市。预计数据量以每年4-8倍的数据量增加。
目标：
保证调整后在未来3-5年左右依旧比较合理，数据库层面不成为整体架构的瓶颈，能较方便的扩展。
核心问题
1 单表单库数据量过大，磁盘占用过大，甚至磁盘不够使用，导致索引效率逐渐变低、查询过于耗费cpu io等资源。-- 目前问题
2 业务关联性低或者绝对并发量高，数千级别，数据库读写压力大，太多slave，已经达到单个库实例的极限。
3个解决方向:
0 分区 -- 单机限制，且mysql对分区的支持越来越弱，部分功能已启用。
1 分库分表，使用sharding sphere和mycat等。
2 使用分布式数据库，如TiDB，PolarDB ,drds等。
详细对比如下：
| 分库分表(shardingSphere) | 分布式数据库(TiDB) | |
| 事务 | 支持 | 支持 |
| 业务侵入性 | 高 | 无(且直接兼容mysql协议，无需修改代码) |
| 唯一索引，全局id | 不支持 | 支持 |
| 索引查询 | 分别查询后聚合，效率较低 | 直接走索引，效率高 |
| 多维度查询 | 非分片维度的查询极慢，需要单独处理 | 支持 |
| 跨库查询 | 不支持跨库join等 | 无该问题 |
| 数据生命周期 | 无 | 冷热数据 |
| 后期扩展性（数据、编发量暴增） | 需要再次分表、分库，成本超级大 | 支持水平弹性扩展，支持大量高并发写入 |
| 高可用性 | 需要单独配置 | 金融级别高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移 |
| 表结构修改 | 千万级别要数十分钟 | 秒级别 |
| 数据分析/挖掘 | 需要数据仓库等，后期复杂度会越来越高 | 支持，提供了组件(TiSpark TiFlash)，支持同时OLTB和OLAB。 |
| 架构复杂度 | 低 | 高 |
| 硬件要求 | 低 | 高，需要SSD磁盘，CPU内存消耗大,但硬件价格一直在下降。且数据量上来(十亿)之后，相对mysql更节约资源。 |
| 技术复杂度 | 低 | 较高 |
| 云原生 | --- | 提供了 TiDB Operator |
| 生态与发展 | Githup 15K star | 美团 滴滴 网易 360 知乎 汽车之家 Githup 30K star |
TiDB能从根本上避免数据库后期称为整个系统的瓶颈。
