拆分方式
垂直拆分
更多是从业务角度拆分，主要是降低业务耦合度，如果一行数据字段越多，那么占用数据就越大，那么每一页存储的数据自然越少，那么查询所需 IO 次数就越高因此性能更差。
水平拆分
水平拆分更多是从技术角度进行拆分，拆分后每张表的结构都是一模一样的，简而言之就是通过技术手段进行分片到多张表存储，数据量越少，索引树深度越浅，减少磁盘扫描范围。
分库分表
什么适合分库什么时候分表、什么适合读写分离
- 读 qps 高，读写分离
- 写 qps 高，导致数据库连接不足，分库
- 单表数据量大，并发不大，水平分表，减少磁盘扫描范围
ShardingSphere
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈
shardingsphere.apache.org/index_zh.ht…
| ****** | Sharding-JDBC | Sharding-Proxy | Sharding-Sidecar |
|---|---|---|---|
| 数据库 | 任意 | MySQL | MySQL |
| 连接消耗数 | 高 | 低 | 高 |
| 异构语言 | 仅Java | 任意 | 任意 |
| 性能 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 是 | 否 | 是 |
| 静态入口 | 无 | 有 | 无 |
Sharding-JDBC
- 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供额外服务
- 它使用客户端直连数据库，以 jar 包形式提供服务
- 可以理解为增强版的 JDBC 驱动，完全可以兼容 JDBC 和各种 ORM 框架
ShardingSphere-JDBC 和 ShardingSphere-Proxy 区别
- Sharding-JDBC 是一个 jar 包，底层通过重写 JDBC 组件完成 SQL 解析、路由、改写、执行等流程，需要在项目中添加对应功能的配置文件，对应用有一定侵入性
- 应用通过 Sharing-JDBC 是直接操作数据库，相当于只有一次网络 IO，而应用连接 Proxy 是一次网络 IO ，Prxoy 再次操作数据库又是一次网络 IO，应用调用链路增加一层，容易形成流量瓶颈，对应用增加了潜在的风险
- Sharing-JDBC 易于实现，方便运维
- Sharding-Proxy 是一个进程服务，将自己伪装成一个数据库，应用对接后对代码无侵入，对 SQL 的执行逻辑同 Sharding-JDBC 一致
