09数据库优化方案（二）如何实现分库分表？

　　前一章节，我们对数据库做了主从同步，主库用来写入数据，从库用来分担查询，从而抵抗大并发的流量。
　　那么随着系统上线时间的问题，用户注册也越来越多，数据库存储也越来越大，单个表的数据量超过了千万级设置亿级别，这个时候即使你使用了索引，索引随着数据量的增大占用的空间也增大，数据库无法缓存全量的索引信息，那就需要从磁盘上读取索引数据，影响查询性能，那么这个时候如何提升查询性能呢？
　　数据量的增加也占据了磁盘的空间，数据库的备份和恢复的时间变长，如何让数据库支撑如此大的数据量？
　　现在不同的模块数据库，比如用户和用户关系模块目前数据还是保存在一个主库中，一旦发生故障，所有模块都要收到影响，那么就自然想到不同的模块如何做到隔离呢？
　　你已经知道了，在 4 核 8G 的云服务器上对 MySQL 5.7 做 Benchmark，大概可以支撑 500TPS 和 10000QPS，那么随着系统写入量的增加，数据库系统如何来处理更高的并发写入量请求呢？
　　数据库的写入量大造成性能和可用性方面的问题，要解决这些问题，采取的措施就是对数据进行分片。这样可以很好的分摊数据的读写压力，突破单标瓶颈，常见的就是对数据进行   分库分表
　　分库分表是一种常见切成熟的方案，那么这种方案会有哪些常见坑呢？  对如何使用分库分表一知半解，没有明白使用场景和方法。比如一些查询不使用分区键。  分库分表引入了一些问题后，没有找到合适的解决方案，比如，会在查询时使用大量的连表查询。  如何对数据库做垂直拆分
　　不同于主从复制全量复制到其他节点，分库分表后，每个节点只存储部分数据，这样可以有效减少单个节点的数据量，解决了数据存储瓶颈的同时，也有效提升了数据库的写入和查询性能。
　　数据库分库分表有两种方式，一种是垂直拆分，另一种是水平拆分，这两种方式 掌握核心业务是关键。
　　以微博为例说明，有用户相关的表，有内容相关的表，这些都存储在主库中，才拆分后，我们期望用户相关的表拆分到主库中，内容相关的表拆分到内容库中，关联先关表拆分到关系库中。
　　对数据库进行垂直拆分是一种常规方式，拆分之后虽然解决了单库存储压力的问题，但是并不能解决单一模块表存储量的问题。
　　比如微博的关系量早已过千亿，单一数据库或者表已经不能满足存储和查询的需求了。这个时候就需要对数据做多个数据库和数据表的拆分了。  如何对数据库做水平拆分
　　与垂直拆分关注业务相关性不同，水平拆分一般对同一业务模块数据按照一定规则，分散到多个数据库和数据表中。拆分的规则有下面这两种：  按照某一个字段的哈希值做拆分，这种拆分规则比较适用于实体表中，比如说用户表，内容表，一般按照这些实体表的Id字段来拆分。比如我们分了 16库 64张表，那么我们可以先对 Id hash 值，目的是尽量将 Id 打散，然后对 16取余就得到了库的序号，对64取余就得到了表的索引值。  一般来说根据时间维度来增加的数据，比如时序数据采用这种方式来分库分表比较适合。解决分库分表引入的问题分库分表引入带来最大的问题就是分库分表建或者叫做分区键，也就是我们数据库分库分表所依据的字段。从分库分表的规则来看，无论是哈希 还是区间段的方式，之后所有的查询都需要带上这个 分库分表字段。否则的话就可能会发生全表扫描的情况，这个情况是不能接收到额。  思路总比办法多  通常我们会创建一个中间关联表，比如你需要通过昵称查询用户，这个时候你需要创建一张昵称跟Id 的关联表。通过昵称先查到id 再根据Id 去分库分表查询。当然这个关联表也可以是分库分表，因为字段比较少，所以占用空间还好。分库分表带来的另一个问题就是关联查询的问题。单库单表的时候 可以通过 Join解决，但是拆分之后就无法跨库关联查询了。这个时候一些逻辑可能就需要我们放在业务层来实现了。比如过滤或者引入Redis 来暂时缓存需要归并的数据等。虽然分库分表给我们带来了这么多麻烦，那这么做是否有必要呢？当然有的，这样让我们突破了单库单表的瓶颈，为业务的大数据量存储和高并发 提供了可能。对于分库分表的原则主要有以下几点：如果性能上没有瓶颈就尽量不要做分库分表如果要做，就一次到位，比如 16库 64 表满足你几年内的业务增长量，否则做数据迁移也是需要综合评估方案很多的 NoSQL 数据库提供了 自动 sharding 功能，如果团队有这方面运维能力，也可以直接用来代替关系数据库