8个 数据库性能优化方案，你知道几个？（建议收藏） 上

毫不夸张的说咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论，能让大家快速、准确的去选择出合适的优化方案，我相信能够快速准备解决咱么日常遇到的80%甚至90%的性能问题。

从解决问题的角度出发，我们得先了解到问题的原因；其次我们得有一套思考、判断问题的流程方式，让我们合理的站在哪个层面选择方案；最后从众多的方案里面选择一个适合的方案进行解决问题，找到一个合适的方案的前提是我们自己对各种方案之间的优缺点、场景有足够的了解，没有一个方案是完全可以通吃通用的，软件工程没有银弹。

下文是我工作多年以来，曾经使用过的八大方案，结合了平常自己学习收集的一些资料，以系统、全面的方式整理成了这篇博文，也希望能让一些有需要的同行在工作上、成长上提供一定的帮助。

无论是关系型数据库还是 NoSQL，任何存储系统决定于其查询性能的主要有三种：

查找的时间复杂度

数据总量

高负载

而决定于查找时间复杂度主要有两个因素：

查找算法

存储数据结构

无论是哪种存储，数据量越少，自然查询性能就越高，随着数据量增多，资源的消耗（CPU、磁盘读写繁忙）、耗时也会越来越高。

从关系型数据库角度出发，索引结构基本固定是B+Tree，时间复杂度是O(log n)，存储结构是行式存储。因此咱们对于关系数据库能优化的一般只有数据量。

而高负载造成原因有高并发请求、复杂查询等，导致CPU、磁盘繁忙等，而服务器资源不足则会导致慢查询等问题。

该类型问题一般会选择集群、数据冗余的方式分担压力。

从上图可见，自顶向下的一共有四层，分别是硬件、存储系统、存储结构、具体实现。

层与层之间是紧密联系的，每一层的上层是该层的载体；因此越往顶层越能决定性能的上限，同时优化的成本也相对会比较高，性价比也随之越低。

以最底层的具体实现为例，那么索引的优化的成本应该是最小的，可以说加了索引后无论是 CPU 消耗还是响应时间都是立竿见影降低。

然而一个简单的语句，无论如何优化加索引也是有局限的，当在具体实现这层没有任何优化空间的时候就得往上一层【存储结构】思考，思考是否从物理表设计的层面出发优化（如分库分表、压缩数据量等），如果是文档型数据库得思考下文档聚合的结果。

如果在存储结构这层优化得没效果，得继续往再上一次进行考虑，是否关系型数据库应该不适合用在现在得业务场景？

如果要换存储，那么得换什么样的 NoSQL?

所以咱们优化的思路，出于性价比的优先考虑具体实现，实在没有优化空间了再往上一层考虑。当然如果公司有钱，直接使用钞能力，绕过了前面三层，这也是一种便捷的应急处理方式。

该篇文章不讨论顶与底的两个层面的优化，主要从存储结构、存储系统中间两层的角度出发进行探讨。

数据库的优化方案核心本质有三种：减少数据量、用空间换性能、选择合适的存储系统。

这也对应了开篇讲解的慢的三个原因：数据总量、高负载、查找的时间复杂度。

这里大概解释下收益类型：短期收益，处理成本低，能紧急应对，久了则会有技术债务；长期收益则跟短期收益相反，短期内处理成本高，但是效果能长久使用，扩展性会更好。

静态数据意思是，相对改动频率比较低的，也无需过多联表的，where 过滤比较少。动态数据与之相反，更新频率高，通过动态条件筛选过滤。

减少数据量类型共有四种方案：数据序列化存储、数据归档、中间表生成、分库分表。

就如上面所说的，无论是哪种存储，数据量越少，自然查询性能就越高，随着数据量增多，资源的消耗（CPU、磁盘读写繁忙）、耗时也会越来越高。

目前市面上的 NoSQL 基本上都支持分片存储，所以其天然分布式写的能力从数据量上能得到非常的解决方案。

而关系型数据库，查找算法与存储结构是可以优化的空间比较少，因此咱们一般思考出发点只有从如何减少数据量的这个角度进行选择优化，因此本类型的优化方案主要针对关系型数据库进行处理。

注意点：别一次性迁移数量过多，建议低频率多次限量迁移。像MySQL由于删除数据后是不会释放空间的，可以执行命令OPTIMIZE TABLE释放存储空间，但是会锁表，如果存储空间还满足，可以不执行。

建议优先考虑该方案，主要通过数据库作业把非热点数据迁移到历史表，如果需要查历史数据，可新增业务入口路由到对应的历史表（库）。

在数据库以序列化存储的方式，对于一些不需要结构化存储的业务来说是一种很好减少数据量的方式，特别是对于一些M*N的数据量的业务场景，如果以M作为主表优化，那么就可以把数据量维持最多是M的量级。

另外像订单的地址信息，这种业务一般是不需要根据里面的字段检索出来，也比较适合。

这种方案我认为属于一种临时性的优化方案，无论是从序列化后丢失了部份字段的查询能力，还是这方案的可优化性都是有限的。

中间表（结果表）其实就是利用调度任务把复杂查询的结果跑出来存储到一张额外的物理表，因为这张物理表存放的是通过跑批汇总后的数据，因此可以理解成根据原有的业务进行了高度的数据压缩。

以报表为例，如果一个月的源数据有数十万，我们通过调度任务以月的维度生成，那么等于把原有的数据压缩了几十万分之一。

接下来的季报和年报可以根据月报 *N 来进行统计，以这种方式处理的数据，就算三年、五年甚至十年数据量都可以在接受范围之内，而且可以精确计算得到。

那么数据的压缩比率是否越低越好？

下面有一段口诀：

字段越多，粒度越细，灵活性越高，可以以中间表进行不同业务联表处理。

字段越少，粒度越粗，灵活性越低，一般作为结果表查询出来。

分库分表作为数据库优化的一种非常经典的优化方案，特别是在以前 NoSQL 还不是很成熟的年代，这个方案就如救命草一般的存在。

如今也有不少同行也会选择这种优化方式，但是从我角度来看，分库分表是一种优化成本很大的方案。这里我有几个建议：

分库分表是实在没有办法的办法，应放到最后选择。

优先选择 NoSQL 代替，因为 NoSQL 诞生基本上为了扩展性与高性能。

究竟分库还是分表？量大则分表，并发高则分库

不考虑扩容，一部做到位。因为技术更新太快了，每 3-5 年一大变。

只要涉及到这个拆，那么无论是微服务也好，分库分表也好，拆分的方式主要分两种：垂直拆分、水平拆分。

垂直拆分更多是从业务角度进行拆分，主要是为了降低业务耦合度；此外以 SQL Server 为例，一页是 8KB 存储，如果在一张表里字段越多，一行数据自然占的空间就越大，那么一页数据所存储的行数就自然越少，那么每次查询所需要 IO 则越高因此性能自然也越慢；因此反之，减少字段也能很好提高性能。

之前我听说某些同行的表有 80 个字段，几百万的数据就开始慢了。

水平拆分更多是从技术角度进行拆分，拆分后每张表的结构是一模一样的，简而言之就是把原有一张表的数据，通过技术手段进行分片到多张表存储，从根本上解决了数据量的问题。

进行水平拆分后，根据分区键（sharding key）原来应该在同一张表的数据拆解写到不同的物理表里，那么查询也得根据分区键进行定位到对应的物理表从而把数据给查询出来。

路由方式一般有三种：区间范围、Hash、分片映射表。每种路由方式都有自己的优点和缺点，可以根据对应的业务场景进行选择。

区间范围根据某个元素的区间的进行拆分，以时间为例子，假如有个业务我们希望以月为单位拆分那么表就会拆分像 table_2022-04，这种对于文档型、ElasticSearch 这类型的 NoSQL 也适用，无论是定位查询，还是日后清理维护都是非常的方便的。那么缺点也明显，会因为业务独特性导致数据不平均，甚至不同区间范围之间的数据量差异很大。

Hash 也是一种常用的路由方式，根据 Hash 算法取模以数据量均匀分别存储在物理表里，缺点是对于带分区键的查询依赖特别强，如果不带分区键就无法定位到具体的物理表导致相关所有表都查询一次，而且在分库的情况下对于 Join、聚合计算、分页等一些 RDBMS 的特性功能还无法使用。

一般分区键就一个，假如有时候业务场景得用不是分区键的字段进行查询，那么难道就必须得全部扫描一遍？

其实可以使用分片映射表的方式。

简单来说就是额外有一张表记录额外字段与分区键的映射关系。

举个例子，有张订单表，原本是以 UserID 作为分区键拆分的，现在希望用 OrderID 进行查询，那么得有额外得一张物理表记录了 OrderID 与 UserID 的映射关系。因此得先查询一次映射表拿到分区键，再根据分区键的值路由到对应的物理表查询出来。

可能有些朋友会问，那这映射表是否多一个映射关系就多一张表，还是多个映射关系在同一张表？

我优先建议单独处理，如果说映射表字段过多，那跟不进行水平拆分时的状态其实就是一致的，这又跑回去的老问题。