垂直分库针对的是一个系统中的不同业务进行拆分，比如用户User一个库，商品Product一个库，订单Order一个库 。切分后，要放在多个服务器上，而不是一个服务器上 。为什么？ 我们想象一下，一个购物网站对外提供服务 ， 会有用户，商品，订单等的CRUD 。没拆分之前，全部都是落到单一的库上的 ， 这会让数据库的单库处理能力成为瓶颈 。按垂直分库后 ， 如果还是放在一个数据库服务器上 ， 随着用户量增大 ， 这会让单个数据库的处理能力成为瓶颈，还有单个服务器的磁盘空间，内存，tps等非常吃紧 。所以我们要拆分到多个服务器上，这样上面的问题都解决了，以后也不会面对单机资源问题 。
数据库业务层面的拆分，和服务的“治理”，“降级”机制类似 ， 也能对不同业务的数据分别的进行管理，维护 ， 监控 ， 扩展等 。数据库往往最容易成为应用系统的瓶颈，而数据库本身属于“有状态”的，相对于Web和应用服务器来讲，是比较难实现“横向扩展”的 。数据库的连接资源比较宝贵且单机处理能力也有限，在高并发场景下 ， 垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈 。
水平分表
针对数据量巨大的单张表（比如订单表） ， 按照某种规则（RANGE,HASH取模等），切分到多张表里面去 。但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈 。不建议采用 。
水平分库分表
将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表 ， 只是表中数据集合不同 。水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈 。
水平分库分表切分规则
1. RANGE
从0到10000一个表，10001到20000一个表；
2. HASH取模
一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题 。取用户id，然后hash取模，分配到不同的数据库上 。
3. 地理区域
比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此 。
4. 时间
按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝 ， 这些表的数据 被查询的概率变小 ， 所以没必要和“热数据”放在一起，这个也是“冷热数据分离” 。
分库分表后面临的问题
事务支持
分库分表后，就成了分布式事务了 。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担 。
跨库join
只要是进行切分，跨节点Join的问题是不可避免的 。但是良好的设计和切分却可以减少此类情况的发生 。解决这一问题的普遍做法是分两次查询实现 。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据 。
跨节点的count,order by,group by以及聚合函数问题
这些是一类问题，因为它们都需要基于全部数据集合进行计算 。多数的代理都不会自动处理合并工作 。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并 。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多 。但如果结果集很大，对应用程序内存的消耗是一个问题 。
数据迁移，容量规划，扩容等问题
推荐阅读
- thinkphp互站源码，thinkphp 建站
- sqlserver无项目，sql2000数据库无项目
- mysql黑框怎么弄 mysql黑框闪退
- 电商白酒销量如何，白酒电商平台哪个好
- 公众号阅读来源未知，公众号阅读来源历史消息
- js修改一个标签的css样式表，js如何修改css
- python中的函数单词 python 函数中的函数
- 什么cpu有vega11，什么CPU有大小核
- 公众号关注后有什么影响吗，公众号关注多了会封号吗