前言
公司最近在搞服务拆分的内容，由于服务拆分必然会带来数据库的拆分，
同时公司业务单表数据最高已经达到了亿级，于是乎考虑分库分表来对库进行拆分
所以将分库分表提上日程必然是势在必行
特此记录一下对分库分表的研究历程
何谓
分库分表，字面意思就给人一种手艺活的感觉
既然是一门手艺活，那么当然得先从姿势讲起（手动❀鸡）
垂直
- 垂直分表：大表拆分成小表，由于大表有很多字段，但是有部分简单查询时这些字段并不常用，因此可以拆分成基础信息表和详细信息表。
- 垂直分库：大库拆分成小库，一般是按照服务来进行拆分，比如订单库，用户库。
水平
- 水平分表：将表的行数据进行拆分，比如主键为偶数的表放到order_1表，主键为奇数的数据放到order_2表
- 水平分库：和水平分表逻辑类似，将数据按照一定规则在不同的库上进行分配
何时需要
数据库在一个公司的架构中，作为最底层的基础建设，对各种上层应用提供数据服务支撑，很容易在整个架构的性能上形成一定瓶颈，常见现象有如下几种：
- 数据库连接过多
- 查询经过索引等优化后无法满足日常查询
- 读写分离已经无法满足
注意点
- 分库后如何处理事务
- 多数据源管理
- 跨库join操作
如何落实
- ShardingSphere
- MyCat
总结
- 分库分表之前要慎重，因为涉及到数据的变更，可能业务代码上还需要作改动
- 分库分表的优先级一般位于所有优化方案之后，在索引或读写分离等优化方案无法满足后，如果这些方式不能根本解决问题，才进行分库分表
- 数据库设计之初就考虑分库分表，但是不推荐直接分库分表，大多数的产品还是以满足功能和使用为为前提，提前分库分表无疑会增加开发成本