专项攻克——分库分表

参考博客：分库分表的基本思想

先简单介绍一下基本概念，详情请参考别人写的这个博客，还算nice！

一、基本思想

Sharding基本思想：把一个数据库切分成多个部分放到不同的数据库(server)上，以缓解单一数据库的性能问题。

对于海量数据的数据库：
（1）如果是因为表多导致的数据量多，这时候适合使用垂直切分，即把关系紧密（比如同模块）的表切分出来放在一个server上。
（2）如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。

当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。

二、垂直与水平

2.1 垂直分表

是将宽表变成几个窄表的手段，每个表存储其中一部分字段。一般会将常用的重要字段剥离放到窄表中，将不常用的字段放到另一个表中。

垂直分表的优势：

1. 避免IO竞争减少锁表的概率。因为大的字段效率更低，第一数据量大，需要的读取时间长。
2. 大字段占用的空间更大，单页内存储的行数变少，会使得IO操作增多。可以更好地提升热门数据的查询效率。窄表的每个页容纳能更多的行，减少跨页检索，减少磁盘扫描范围，达到高效的目的。

2.2 水平分表

在同一个数据库内，可以通过HASH、范围、取模、时间等手段拆分，把同一个表按照一定规则拆分到多个表中。

水平分表的优势：

1. 解决了单表数据量过大的问题
2. 避免IO竞争并减少锁表的概率

2.3 垂直分库

对表按照业务分类，部署到不同的数据库上面，（不同的数据库可以放到不同的服务器上）。

例：一个数据库里面存放着用户数据（用户表），又存储订单数据（订单表），那么使用垂直分库可以把用户数据放到用户库、把订单数据放到订单库。

垂直分库的优势：
降低业务中的耦合，方便对不同的业务进行分级管理。
可以提升IO、数据库连接数、解决单机硬件资源的瓶颈问题。

垂直拆分（分库、分表）的缺点：
主键出现冗余，需要管理冗余列
事务的处理变得复杂
仍然存在单表数据量过大的问题

2.4 水平分库

把同一个表按照一定规则，比如通过HASH、范围、取模、时间等手段，拆分到不同的数据库中，（不同的数据库可以放到不同的服务器上）。

水平分库的优势：
解决了单库大数据量的瓶颈问题
IO冲突减少，锁的竞争减少，某个数据库出现问题不影响其他数据库（可用性），提高了系统的稳定性和可用性

水平拆分（分表、分库）的缺点：
分片事务一致性难以解决
跨节点JOIN性能差，逻辑会变得复杂
数据扩展难度大，不易维护
在系统设计时应根据业务耦合来确定垂直分库和垂直分表的方案，在数据访问压力不是特别大时应考虑缓存、读写分离等方法，若数据量很大，或持续增长可考虑水平分库分表，水平拆分所涉及的逻辑比较复杂，常见的方案有客户端架构和恶代理架构。

分库分表后，ID键如何处理？

分库分表后不能每个表的ID都是从1开始，所以需要一个全局ID，设置全局ID主要有以下几种方法：

1. UUID：优点：本地生成ID，不需要远程调用；全局唯一不重复。缺点：占用空间大，不适合作为索引。
2. 数据库自增ID（推荐）：在分库分表表后使用数据库自增ID，需要一个专门用于生成主键的库，每次服务接收到请求，先向这个库中插入一条没有意义的数据，获取一个数据库自增的ID，利用这个ID去分库分表中写数据。优点：简单易实现。缺点：在高并发下存在瓶颈。系统结构如下图（图片来源于网络）