前言
随着业务的快速增长和数据量的爆炸性增加，传统的单体数据库架构已经难以满足性能和扩展性的需求。为了解决这一问题，分库分表技术应运而生，成为支撑大规模业务的重要手段。
分库分表方式
中间件
- Cobar：阿里巴巴开发的分库分表中间件，支持自动分片和路由
- TDDL（Tencent Database Linker）：腾讯开发的分库分表中间件，支持多种分片策略
- Atlas：由LinkedIn开发的分库分表中间件，支持自动分片和路由
- Sharding-JDBC：阿里巴巴开发的Java库，用于实现数据库的分库分表功能
- MyCat：一个基于MySQL的分库分表中间件，支持数据的横向扩展
- ShardingSphere：阿里云开源的分布式数据库中间件解决方案，提供数据分片、分布式事务和数据库治理功能。
客户端
业务层自己实现分库分表算法
两种方案优缺点
中间件
优点：1.客户端无需关系复杂的分库分表、数据聚合等逻辑
缺点：1.请求链路变长，多了代理这一层。2.问题排查更加复杂
客户端
优点：1.效率更高，直接访问数据库无需经过中间层 2.排查问题更方便
缺点：业务端需要关心复杂的分库分表、数据聚合等逻辑，导致业务层变的很复杂
表设计原则
主键选择：通常选择基于分布式ID生成算法实现的业务ID，不要使用自增主键ID，由于ID是自增的，分表的主键ID也是自增的，会导致分表难度加大。
分表策略：首先要明确数据库出现性能问题一般在数据量到达一定程度后！所以要求我们提前做好预估，不要等需要拆分时再拆，一般把表的数据量控制在千万级别；常用分表策略有两种：按key取模，读写均匀；按时间分，冷热数据明确
案例
假如我们有一个用户信息表，字段包含 id user_id phone name age sex
场景
**用户侧：**根据 user_id 、phone 进行查询, ，user_id 和 phone 是一对一映射关系
**运营侧：**主要后台运营人员使用，查询需求对样，从各种维度查询，姓名、年龄、性别等
架构
**用户侧：**根据 user_id 分表，其它字段建立索引映射表
运营侧：前后端分离或者异构数据（ES、Hbase 等）
流程
用户侧
- 根据 user_id 进行 hash 分表
- user_id =》 phone 建立索引映射表
- user_id 查询，根据 hash 算法查询分表
- Phone 查询，查询索引映射表获取 user_id
- 根据 user_id 进行 hash 算法查询分表
**优化：**如果觉得索引映射表多了一次查询对性能产生影响，也可以把映射关系存入 redis 或 pika 这种大容量、非易失性存储
运营侧
运营侧都是公司内部人员使用，可以创建一个新的读库只供内部人员使用
内部人员使用对性能要求不是特别高，可以考虑不进行分表，建立好相应索引
如果查询需求比较复杂可以使用异构数据库 ES
总结
分库分表是应对大数据量和高并发场景的有效手段。选择合适的分库分表策略和中间件对于保证系统的可扩展性和高性能至关重要。在设计数据库时，应考虑主键的选择和分表策略，以实现数据的合理分布。同时，业务层和运营侧的需求也应得到充分的考虑，以确保系统的灵活性和可维护性。通过不断优化和实践，我们可以构建出既高效又稳定的数据库架构。
Reference
- https://juejin.cn/post/6844903491266166792
- https://juejin.cn/post/6897249714052268039?from=search-suggest
- https://tech.meituan.com/2016/11/18/dianping-order-db-sharding.html
