随着单库中的数据量越来越大、数据库的查询QPS越来越高，相应的，对数据库的读写所需要的时间也越来越多。数据库的读写性能可能会成为业务发展的瓶颈。对应的，就需要做数据库性能方面的优化。

场景一：如果数据库的查询QPS【连接数】过高，就需要考虑拆库，通过分库来分担单个数据库的连接压力。比如，如果查询QPS为3500，假设单库可以支撑1000个QPS的话，那么就可以考虑拆分成4个库，来分散查询连接压力。

场景二：如果单表数据量过大，就需要考虑分表，当数据量超过一定量级后，无论是对于数据查询还是数据更新，在经过索引优化等纯数据库层面的传统优化手段之后，还是可能存在性能问题。这是量变产生了质变，这时候就需要去换个思路来解决问题，比如：从数据生产源头、数据处理源头来解决问题，既然数据量很大，那我们就来个分而治之，化整为零。这就产生了分表，把数据按照一定的规则拆分成多张表，来解决单表环境下无法解决的存取性能问题。

场景三：如果单数据库宕机，可能所有数据都会丢失，就需要考虑数据拆分

  • 单库部署情况下，如果数据库宕机，那么故障影响就是100%，而且恢复可能耗时很长。
  • 如果我们拆分成2个库，分别部署在不同的机器上，此时其中1个库宕机，那么故障影响就是50%，还有50%的数据可以继续服务。
  • 如果我们拆分成4个库，分别部署在不同的机器上，此时其中1个库宕机，那么故障影响就是25%，还有75%的数据可以继续服务，恢复耗时也会很短。

当然，我们也不能无限制的拆库，这也是牺牲存储资源来提升性能、可用性的方式，毕竟资源总是有限的。

分库分表是什么

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成 ，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

分库分表有哪些

分库分表包括分库和分表两个部分，在生产中通常包括：垂直分表、垂直分库、水平分库、水平分表四种方式

垂直分表

在电商的场景中，商品往往只会在用户感兴趣的时候才会查看该商品的详细描述，因此，商品信息中商品详情访问的频率没有那么高，而且一般占用的内存空间会较大，访问单个数据IO时间较长

反之，商品名称，图片和价格等这些关键性字段的访问频率较高。

针对这两种数据的特性，我们可以考虑进行垂直分表，访问频率低的商品详情单独拆分为一张表，访问频率高的字段放在一张表，通过商品的id进行关联

image-20220409012707355

垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段

优点：

  • 为了避免IO争抢并减少锁表的几率，查看详情的用户与商品信息浏览互不影响
  • 充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累

一般来说，某业务实体中的各个数据项的访问频次是不一样的，部分数据项可能是占用存储空间比较大的BLOB或是TEXT。例如上例中的商品描述。所以，当表数据量很大时，可以将表按字段切开，将热门字段、冷门字段分开放置在不同库中，这些库可以放在不同的存储设备上，避免IO争抢。

垂直切分带来的性能提升主要集中在热门数据的操作效率上，而且磁盘争用情况减少。

通常我们按以下原则进行垂直拆分：

  • 把不常用的字段单独放在一张表
  • 把text，blob等大字段拆分出来放在附表中
  • 经常组合查询的列放在一张表中

垂直分库

通过垂直分表性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终限制在一台服务器，库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同的服务器上，因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。

image-20220410141146891

垂直分库定义：按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用

优点：

  • 解决业务层面的耦合，业务清晰
  • 能对不同业务的数据进行分级管理、维护、监控、扩展等
  • 高并发场景下，垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈

垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题

水平分库

经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，PRODUCT_DB(商品库)单库存储数据已经超出预估。粗略估计，目前有8w店铺，每个店铺平均150个不同规格的商品，再算上增长，那商品数量得往1500w+上预估，并且PRODUCT_DB(商品库)属于访问非常频繁的资源，单台服务器已经无法支撑。此时该如何优化？

这时候我们需要考虑使用水平分库，通过分库规则将商品信息分别放在两个库中

image-20220410141729502

也就是说，要操作某条数据，先分析这条数据所属的店铺ID。如果店铺ID为双数，将此操作映射至RRODUCT_DB1(商品库1)；如果店铺ID为单数，将操作映射至RRODUCT_DB2(商品库2)。此操作要访问数据库名称的表达式为RRODUCT_DB[店铺ID%2 + 1] 。

水平分库定义：是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上

优点：

  • 解决了单库大数据，高并发的性能瓶颈
  • 提高了系统的稳定性及可用性

当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平分库了，经过水平切分的优化，往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大提升了系统复杂度

水平分表

按照水平分库的思路对他把PRODUCT_DB_X(商品库)内的表也可以进行水平拆分，其目的也是为解决单表数据量大的问题

image-20220410142038513

与水平分库的思路类似，不过这次操作的目标是表，商品信息及商品描述被分成了两套表。

如果商品ID为双数，将此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1]

水平分表定义：在同一个数据库内，把同一个表的数据按一定规则拆到多个表中

优点：

  • 优化单一表数据量过大而产生的性能问题
  • 避免IO争抢并减少锁表的几率

库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个表的数据量变小，提高检索性能

小结

一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案，因为它也会带来一些问题：

  • 事务一致性问题

    由于分库分表把数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题

  • 跨节点关联查询

    在没有分库前，我们检索商品时可以通过以下SQL对店铺信息进行关联查询： 

    1
    SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] FROM [商品信息] p LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] WHERE...ORDER BY...LIMIT...

    但垂直分库后**[商品信息]和[店铺信息]**不在一个数据库，甚至不在一台服务器，无法进行关联查询。

    可将原关联查询分为两次查询，第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据，最后将获得到的数据进行拼装（归并）

  • 跨节点分页，排序函数

    跨节点多库进行查询时limit分页、order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序

    所以请求页数越大，系统的性能也会越差

    在使用Max、Min、Sum、Count之类的函数进行计算的时候，与排序分页同理，也需要先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终将结果返回

  • 主键避重

    在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题

  • 公共表

    实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表

    可以将这类表在每个数据库都保存一份，所有对公共表的更新操作都同时发送到所有分库执行

由于分库分表之后，数据被分散在不同的数据库、服务器。因此，对数据的操作也就无法通过常规方式完成，并且它还带来了一系列的问题。所以使用之前需要把以上会带来的问题仔细考虑进去