共计 3645 个字符，预计需要花费 10 分钟才能阅读完成。
| 导读 | 关系型数据库目前市面上主流无非三种：MySQL、Oracle、SqlServer，笔者更倾向于 MySQL，也是很多新型企业在用的一种数据库，因此本篇文章也将重点围绕 MySQL 展开。 |
在前面的文章中探讨了架构优化的两种方案：冷热分离、查询分离。
查询分离其实就是利用了非关系数据库的高性能，但是不足之处也很明显：当主数据量越来越多，写操作缓慢；这种问题如何破局？可见任何一种优化方案都不是最终的银弹，只有不断的优化演变
这篇文章就来介绍一下解决方案：分库分表，将围绕以下几点介绍：
在介绍选型之前先来介绍下架构背景，笔者曾经做过电商系统的优化，该系统中包含的两个主体：
对于如此量级的数据，单库单表的情况下，无论是 IO 还是 CPU 都扛不住，架构上的优化是必然。
经过了多次探讨尝试，最终选择了分库分表。
说到分库分表首先想到的就是存储选型，关于持久层的选型主流的无非有如下几种：
关系型数据库目前市面上主流无非三种：MySQL、Oracle、SqlServer，笔者更倾向于 MySQL，也是很多新型企业在用的一种数据库，因此本篇文章也将重点围绕 MySQL 展开
在任何系统中关系型数据库的地位都是不可或缺的，它的强约束性、事务的控制、SQL 语法、锁 …. 这些功能可谓是久经考验，因此在功能上 MySQL 能满足我们所有的业务需求。
说到 NoSQL，第一个想到就是 MongoDB，它的分片功能从并发性和数据量这两个角度已经能满足一般大数据量的需求，但是仍然需要考虑如下几点：
约束性：MongoDB 不是关系型数据库而是文档型数据库，它的每一行记录都是一个结构灵活可变的 JSON，比如存储非常重要的订单数据时，我们就不能使用 MongoDB，因为订单数据必须使用强约束的关系型数据库进行存储。
业务功能考量：事务的控制、SQL 语法、锁以及各种千奇百怪的 SQL 在已有的架构上都曾久经考验，但是 MongoDB 在这些功能需要上并不能满足
业务改造考量：未拆分前使用关系型数据库，使用 NoSQL 之后对于 SQL 的改造比较麻烦，项目周期更长
NewSQL 目前比较主流则是 TiDB，该技术比较新，虽然能够满足大数据量的存储，但是在选择上还是需要做些考量：
熟悉程度考量：如果你所在公司架构组对于 NewSQL 比较数据或者已经有在使用，则可以选择
稳定性考量：关系型数据毕竟是久经考验，在稳定性方面肯定是比较好，但是 NewSQL 的稳定性却无法去考量，建议初期阶段可以将一些不太重要的数据使用 NewSQL 存储
什么是分表分库？分表是将一份大的表数据拆分存放至多个结构一样的拆分表；分库就是将一个大的数据库拆分成多个结构一样的小库。
前面介绍的三种拆分存储技术，在我以往的项目中我都没使用过，而是选择了基于 MySQL 的分表分库，主要是有一个重要考量：分表分库对于第三方依赖较少，业务逻辑灵活可控，它本身并不需要非常复杂的底层处理，也不需要重新做数据库，只是根据不同逻辑使用不同 SQL 语句和数据源而已。
目前市面上主流的分库分表分为两种模式：Proxy 模式、Client 模式
Proxy 模式属于业务无侵入型，直接代理数据库，对于开发者一切都是无感知的，SQL 组合、数据库路由、执行结果合并等功能全部存放在一个代理服务中，比如 MyCat、ShardingSphere 都对 Proxy 模式提供了支持
Client 模式属于业务侵入型，将分库分表的逻辑放在客户端，客户端需要引入一个 jar，比如 Sharding-JDBC，架构图如下：
市面上对于分库分表中间件如下：
两种模式的优缺点也很明显：
在落实分表分库解决方案时，我们需要考虑 5 个要点。
针对订单这个业务，其中涉及到以下几个主要的字段：
经过考量，最终选择了 user_id 作为 ShardingKey，为什么呢？
选择 user_id 作为 ShardingKey 需要结合业务场景，订单系统中常见的业务：
以上三种业务场景，判断下优先级，C 端用户肯定是需要优先满足，因此使用 user_id 作为 ShardingKey
这样在查询时需要将 user_id 传递过来才能定位到指定库、表
选择字段作为分片键时，我们一般需要考虑三点要求：数据尽量均匀分布在不同表或库、跨库查询操作尽可能少、这个字段的值不会变（这点尤为重要）。
选择 user_id 作为 ShardingKey 之后，需要考虑使用分片策略了，主要分为如下三种
范围分片
假如 user_id 是自增的数字，则可以根据 user_id 范围进行分片，每 100 万份分为一个库，每 10 万份分为一个表，此时单个库中将分为 10 张表，如下表：
这种方案是根据 Hash 值进行分片，比如 Hash 函数为：hash(user_id%8)，这里是将 user_id 对 8 这个特定值取模，最终分为了 8 张表；这里一般为了方便后续扩容，建议选择 2 的 N 次方
比如先按照范围对 user_id 拆分，每 100 万份分为一个库，在对这 100 万份数据进行 Hash 取模（hash(user_id%8)）拆分成 8 个表
当然以上三种方案的优缺点也是非常明显，这里不再赘述了
需要注意的是：在拆分之前，为了避免频繁的扩容，一定要对未来 5 年或者 10 年数据增长做个判断，预留更多的分片
业务代码的修改这里就不好说了，和自身的业务是强关联。
但是，在这里我想分享一些个人观点。近年来，分表分库操作愈发容易，不过我们需要注意几个要点。
我们已经习惯微服务了，对于特定表的分表分库，其影响面只在该表所在的服务中，如果是一个单体架构的应用做分表分库，那真是伤脑筋。
在互联网架构中，我们基本不使用外键约束。
随着查询分离的流行，后台系统中有很多操作需要跨库查询，导致系统性能非常差，这时分表分库一般会结合查询分离一起操作：先将所有数据在 ES 索引一份，再使用 ES 在后台直接查询数据。如果订单详情数据量很大，还有一个常见做法，即先在 ES 中存储索引字段（作为查询条件的字段），再将详情数据存放在 HBase 中（这个方案我们就不展开了）。
历史数据的迁移非常耗时，有时迁移几天几夜都很正常。而在互联网行业中，别说几天几夜了，就连停机几分钟业务都无法接受，这就要求我们给出一个无缝迁移的解决方案。
还记得讲解查询分离时，我们说过的方案吗？我们再来回顾下，如下图所示：
历史数据迁移时，我们就是采用类似的方案进行历史数据迁移，如下图所示：
此数据迁移方案的基本思路：存量数据直接迁移，增量数据监听 binlog，然后通过 canal 通知迁移程序搬运数据，新的数据库拥有全量数据，且校验通过后逐步切换流量。
数据迁移解决方案详细的步骤如下：
随着业务的发展，如果原来的分片设计已经无法满足日益增长的数据需求，我们就需要考虑扩容了，扩容方案主要依赖以下两点。
分片策略是否可以让新表数据的迁移源只是 1 个旧表，而不是多个旧表，这就是前面我们建议使用 2 的 N 次方分表的原因；
数据迁移：我们需要把旧分片的数据迁移到新的分片上，这个方案与上面提及的历史数据迁移一样，我们就不重复啰唆了。
分表分库的解决方案讲完了，以上就是业界常用的一些做法，不过此方案仍然存在不足之处。
增量数据迁移：如何保证数据的一致性及高可用性
短时订单量大爆发：分表分库仍然扛不住时解决方案是什么？
