一. 数据切分
1、垂直（纵向）切分
2、水平（横向）切分
垂直（纵向）切分
垂直分库
根据业务耦合性，将关联度低的不同表存储在不同的数据库
垂直分表
基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中
水平（横向）切分
1、根据数值范围
2、根据数值取模
水平切分分为库内分表和分库分表，库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。
二. 分库分表带来的问题
1、事务一致性问题
1）分布式事务
2）最终一致性
2、跨节点关联查询 join 问题
1）全局表
系统中所有模块都可能依赖的一些表，为了避免跨库join查询，可以将这类表在每个数据库中都保存一份。
2）字段冗余
利用空间换时间，订单表保存userId时候，也将userName冗余保存一份，
这样查询订单详情时就不需要再去查询"买家user表"了。
3）数据组装
在系统层面，分两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。
最后将获得到的数据进行字段拼装。
4）ER分片
可以先确定表之间的关联关系，并将那些存在关联关系的表记录存放在同一个分片上
这样一来，Data Node1上面的order订单表与orderdetail订单详情表就可以通过orderId进行局部的关联查询了，Data Node2上也一样。
3、跨节点分页、排序、函数问题
需要先在每个分片上执行相应的函数、排序等，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回。
4、全局主键避重问题
1）UUID
2）结合数据库维护主键ID表
3）Snowflake分布式自增ID算法
5、数据迁移、扩容问题
面临性能和存储的瓶颈时，才会考虑分片设计
（一般建议单个分片上的单表数据量不超过1000W）
三. 什么时候考虑切分
1、能不切分尽量不要切分
不到万不得已不用轻易使用分库分表这个大招，避免"过度设计"和"过早优化"。
分库分表之前，先尽力去做：升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。
2、数据量过大，正常运维影响业务访问
1）对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO。
2）对一个很大的表进行DDL修改时，MySQL会锁住全表，这个时间会很长，这段时间业务不能访问此表，影响很大。
3、随着业务发展，需要对某些字段垂直拆分
4、数据量快速增长
随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了
5、安全性和可用性
鸡蛋不要放在一个篮子里。在业务层面上垂直切分，将不相关的业务的数据库分隔，不能因为一个业务把数据库搞挂而牵连到其他业务。
6、什么时候分表
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。