面试官分库分表，真的有必要吗？

　　关于数据库分库分表的面试题已经是烂大街了，面经小册各路神仙的经验分享也是不绝于耳。当然现有的技术解决方案已经是很成熟了。
　　但是想要使用的得心应手，首先应该搞清楚三个问题？为什么使用分库分表？何时使用分库分表？如何分库分表？为什么使用分库分表？
　　答案很简单：当数据库出现性能瓶颈。顾名思义就是数据库扛不住了。
　　数据库出现瓶颈，对外表现有以下几个方面？高并发场景下，大量请求阻塞，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。SQL操作变慢（慢SQL增多）如果数据库中存在一张上亿数据量的表，一条 SQL 没有命中索引会全表扫描，这个查询耗时会非常久。随着业务流量变大存储出现问题，单库数据量越来越大，给存储造成巨大压力。
　　从机器角度，性能瓶颈不外乎就是CPU、磁盘、内存、网络这些，要解决性能瓶颈最简单粗暴的方式就是提升机器性能，但是通过这种方式投入产出比往往不高，也不划算，所以重点还是要从软件层面去解决问题。
　　数据库相关优化方案
　　数据库优化方案很多，主要分为两大类：软件层面、硬件层面。软件层面包括：SQL 调优、表结构优化、读写分离、数据库集群、分库分表等；硬件层面主要是增加机器性能。
　　分库分表其实不是数据库优化方案的最终解决办法，一般来说说能用优化SQL、表结构优化、读写分离等手段解决问题，就不要分库分表，因为分库分表会带来更多需要解决的问题，比如说分布式事务，查询难度增大等。何时使用分库分表？
　　什么时候我们才会选择分库分表？前面已经说了，除了分库分表以外那些软件手段搞不定的时候，我们才会选择分库分表。
　　我们心中可能会有这些疑问？使用分库分表，我们的评判依据是什么？一张表存储了多少数据的时候，才需要考虑分库分表？数据增长速度很快，每天产生多少数据，才需要考虑做分库分表？
　　阿里巴巴开发手册有推荐的思路：单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
　　注意：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。如何分库分表？
　　当前针对分库分表有很多解决方案。这里分两个方面来展开说说：分库 和 分表。分库
　　很多项目前期为了快速迭代，多个应用公用一套数据库，随着业务量增加，系统访问压力增大，系统拆分就势在必行。
　　为了保证业务平滑，系统架构重构也是分了几个阶段进行。多应用单数据库
　　第一个阶段将商城系统单体架构按照功能模块拆分为子服务，比如：Portal 服务、用户服务、订单服务、库存服务等。
　　多应用单数据库如上图，多个服务共享一个数据库，这样做的目的是底层数据库访问逻辑可以不用动，将影响降到最低。多应用多数据库
　　随着业务推广力度加大，数据库终于成为了瓶颈，这个时候多个服务共享一个数据库基本不可行了。我们需要将每个服务相关的表拆出来单独建立一个数据库，这其实就是＂分库＂了。
　　单数据库的能够支撑的并发量是有限的，拆成多个库可以使服务间不用竞争，提升服务的性能。
　　从一个大的数据中分出多个小的数据库，每个服务都对应一个数据库，这就是系统发展到一定阶段必要要做的＂分库＂操作。分表
　　说完了分库，那什么时候才会分表呢？
　　如果系统处于高速发展阶段，拿商城系统来说，一天下单量可能几十万，那数据库中的订单表增长就特别快，增长到一定阶段数据库查询效率就会出现明显下降。
　　因此当表数据增长过快，根据阿里巴巴开发规范中超过500w的数据就要考虑分表了，当然这只是一个经验值，具体要不要分表还要看业务考虑未来三年的一个业务增量。
　　如何分表？
　　分表有几个维度，一是水平切分和垂直切分，二是单库内分表和多库内分表。水平拆分和垂直拆分
　　拿商品表来说，表中分为几类属性：一类是基础属性，例如：商品名称、通用名，商品编码等信息。二类是规格属性：尺寸、型号等信息。三类是拓展属性：描述商品特征的一些属性。我们可以将其拆分为基础信息表、拓展属性表、属性信息表等。这几张表结构不同并且相互独立。但是从这个角度没有解决因为数据量过大而带来的性能问题，因此我们还需要继续做水平拆分。
　　水平拆分表的方法很多种，比如说1w条数据，我们拆分为两个表，id 为基数的放在user1，id为偶数的放在user2中，这样的拆分方式就是水平拆分。
　　其他水平拆分的方式也很多，除了上面按照 id 来拆分，还可以按照时间维度拆分，比如订单表，可以按照每日、每月等进行拆分。每日表：只存储当天你的数据。每月表：可以起一个定时任务将前一天的数据全部迁移到当月表。历史表：同样可以用定时任务把时间超过 30 天的数据迁移到 history表。
　　总结一下水平拆分和垂直拆分的特点：垂直切分：基于表或者字段划分，表结构不同。水平拆分：基于数据划分，表结构相同，数据不同。根据表中字段的某一列特性，分而治之。
　　水平拆分也分两种拆分方式。单库内拆分和多库内拆分单库内拆分和多库内拆分
　　拿针对用户表的拆分来举例，之前的单个用户表按照某种规则拆分为多个子表，多个子表存在于同一数据库中。比如下面用户表拆分为用户1表、用户2表。
　　单库内拆分是在一个数据库中，将一张表拆分为多个子表，一定程度上可以解决单表查询的性能问题，但是也会遇到另外一个问题：但数据库的数据瓶颈。
　　所以在行业内更多的将子表拆分到多个数据库中，如下图，用户表拆分为4个子表，4个子表分两批存在两个不同的数据库中，根据一定的规则进行路由。
　　多库拆分用一句话概括：主要是为了减少单张表数据量大小，解决单表数据量过大带来的性能问题。
　　但是分库分表也带来许多问题。分库分表带来的问题
　　既然分库分表方案那么好，那我们是不是在项目初期就应该采用这种方案呢？莫慌，虽然分库分表解决了很多性能问题，但是同时也给系统带来了很多复杂性。下面我展开说说1. 跨库关联查询
　　之前单体项目，我们想查询一些数据，无脑join就好了，只要数据模型设计没啥问题，关联查询起来其实还是很简单的。现在不一样了，分库分表后的数据可能不在一个数据库，那我们如何关联查询呢？
　　下面推荐几种方式去解决这个问题：字段冗余：把需要关联的字段放到主表中，避免join操作，但是关联字段更新，也会引发冗余字段的更新；数据抽象：通过ETL 等将数据汇总聚合，生成新的表；全局表：一般是一些基础表可以在每个数据库都放一份；应用层组装：将基础数据查出来，通过应用程序计算组装；同特征的数据在一张表：举个例子：同一个用户的数据在同一个库中，比如说我们对订单按照用户id进行分表，订单主表、订单拓展信息表、跟订单有关联查询的表都按照用户id 进行分表，那么同一个用户的订单数据肯定在同一个数据库中，订单维度的关联查询就不存在跨库的问题了。2. 分布式事务
　　单数据库我们可以用本地事务搞定，使用多数据库就只能通过分布式事务解决了。
　　常用的解决方案有：基于可靠消息（MQ）的最终一致性方案、二段式提交（XA）、柔性事务。
　　当然分布式事务相关开源项目推荐两个：Seata 、TX-LCN
　　比较推荐 Seata，阿里出品、大厂加持、如果需要企业级版本支持也是有的。3. 排序、分表、函数计算问题
　　使用SQL 时，order by 、limit 等关键字需要特殊处理，一般都是采用数据分片的思路：现在每个分片路由上执行函数、然后将每个分片路由的结果汇总再计算，然后得出最终结果。
　　开源的解决方案当然也有不少，比较推荐shardingsphere，无论是基于client 或者 基于数据库proxy的都有支持。4. 分布式ID
　　既然分库分表了，主键id已经不能唯一确定我们的业务数据了，随之而来的就是分布式id，顾名思义就是在多个数据库多张表中唯一确定的ID。
　　常见的分布式Id 解决方案有：UUID基于全局数据库自增的ID表基于Redis缓存生成全局ID雪花算法（Snowflake）百度uid-generator（雪花算法的变种）美团Leaf（雪花算法的变种）滴滴Tinyid
　　这些解决方案后面有专门的文章去介绍，这里不过多展开。5. 多数据源
　　分库分表之后可能面临从多个数据库中获取数据，一般的解决方案有，基于 client 适配 和 基于 proxy 适配。
　　比较成熟并且常用的中间件有：shardingsphere（apache顶级项目相当成熟，文档完善）MyCat （社区不太活跃、不推荐）总结
　　如果遇到数据库问题，建议不要着急分库分表。原则是：能不分库分表就不要做。先看下能否通过常规优化手段解决问题。
　　如上所述，引入分库分表虽然可以解决数据库瓶颈问题，但是也给系统带来巨大的复杂性，不是非必须不要使用。设计系统我们一向要本着高可拓展去设计，但是不要过度设计和超前设计。适合当前系统的设计才是最好的。
　　作者：爪哇干货分享
　　链接：https://juejin.cn/post/7186448714779590711