关于介绍分库分表之前
我们需要思考一个问题
为什么要有分库分表呢？他是为了解决什么样的问题呢？
分库分表主要解决的问题是数据量增大的问题
那么有没有别的方式来解决这种问题呢？
有的，比如redis等缓存，但是分库分表并没有像redis缓存一样颠覆了当时的发展，而是在现有体系下的修修补补，更多的是对于当前关系型数据库的一种补充
当前个人以为解决数据量大主要有四种方向：
1.nosql数据库，即使用更高效的非关系型数据库来解决当前的问题
2.读写分离
3.创建索引机制进行优化
4.分库分表
什么是分库分表呢？
分库分表对于库和表都可以进行水平拆分和垂直拆分
先说说什么是垂直拆分吧，为了便于理解，我们可以理解一张表格，竖着一刀切下来，会呈现什么样的效果呢？
每个拆分出来的表都具有不同的结构，但是他们的数据量是一样的
对于数据库来说也是一样的
一个电商的数据库可以拆分成多种库，比如订单数据库，会员数据库，商品数据库等
一个用户user表也可以拆分成比如登录表和用户信息表
个人理解垂直拆分的主要作用是尽可能少的减少不必要信息的检索，比如我要进行用户登录，那我就只需要用户名和密码，我如果把用户的手机号等个人信息全都查出来的话，那我理解其实没什么用，反而还加大了资源的浪费
垂直拆分的特点：
每个表/库的数据结构都不一样
每个表/库的数据都有一列是一样的
每个库/表的并集是全量数据
垂直拆分的优点是拆分之后编写业务逻辑会清晰很多，并且相对来说数据维护会简单，可以按照业务存放在不同的机器上
但是垂直拆分并没有解决数据库数据量大的时候的读写压力大的问题
水平拆分的特点：
每个库表的数据结构都一样
每个库表的数据是完全不同
库/表的并集是全量数据
水平拆分的优点：
单库/表的数据量保持在一定的量，有助于性能的提高
提高了系统的稳定性/负载能力
拆分的表的结构相同，程序改动较小
缺点：
数据的扩容难度较大，维护起来很有难度
拆分规则很难抽象出来
分片事物的一致性问题导致部分事物无法关联只能通过join，只能通过java程序去调用
场景：
根据不同的规则去进行拆分当然要考虑场景了
比如我们要按照orderid还是userid去进行拆分呢？
这个当然要考虑业务场景了
比如你如果是前端用户多，你就要按照userid去进行拆分，因为每个用户更多的只关心自己购买的 东西
比如你是后台管理的用户多（比如警察的内部系统），你就要按照orderid去进行拆分，因为当前的使用人员并不关心每一个用户他具体的信息，而关注的是别的粒度的信息
分库分表也会带来一些问题：
分布式事物的acid问题
跨库join问题
分布式全局唯一id
开发成本高，对编码者要求高