业务单表读写缓慢如何优化？

发布时间：2025-11-05 11:58:35 来源：云智核 作者：应用开发

在前面的业务文章中探讨了架构优化的两种方案：冷热分离、查询分离。单表读写

查询分离其实就是缓慢何优化利用了非关系数据库的高性能，但是业务不足之处也很明显：当主数据量越来越多，写操作缓慢；这种问题如何破局？单表读写可见任何一种优化方案都不是最终的银弹，只有不断的缓慢何优化优化演变

这篇文章就来介绍一下解决方案：分库分表，将围绕以下几点介绍：

在介绍选型之前先来介绍下架构背景，笔者曾经做过电商系统的单表读写优化，该系统中包含的缓慢何优化两个主体：

对于如此量级的数据，单库单表的缓慢何优化情况下，无论是业务IO还是CPU都扛不住，架构上的单表读写优化是香港云服务器必然。

经过了多次探讨尝试，缓慢何优化最终选择了分库分表。

说到分库分表首先想到的就是存储选型，关于持久层的选型主流的无非有如下几种：

1. 关系型数据库

关系型数据库目前市面上主流无非三种：MySQL、Oracle、SqlServer，笔者更倾向于MySQL，也是很多新型企业在用的一种数据库，因此本篇文章也将重点围绕MySQL展开

在任何系统中关系型数据库的地位都是不可或缺的，它的强约束性、事务的控制、SQL语法、锁....这些功能可谓是久经考验，因此在功能上 MySQL 能满足我们所有的业务需求。

2. NoSQL

说到NoSQL，第一个想到就是MongoDB ，IT技术网它的分片功能从并发性和数据量这两个角度已经能满足一般大数据量的需求，但是仍然需要考虑如下几点：

3. NewSQL

NewSQL目前比较主流则是TiDB，该技术比较新，虽然能够满足大数据量的存储，但是在选择上还是免费源码下载需要做些考量：

熟悉程度考量：如果你所在公司架构组对于NewSQL比较数据或者已经有在使用，则可以选择

稳定性考量：关系型数据毕竟是久经考验，在稳定性方面肯定是比较好，但是NewSQL的稳定性却无法去考量，建议初期阶段可以将一些不太重要的数据使用NewSQL存储

什么是分表分库？分表是将一份大的表数据拆分存放至多个结构一样的拆分表；分库就是将一个大的数据库拆分成多个结构一样的小库。

前面介绍的三种拆分存储技术，在我以往的项目中我都没使用过，而是选择了基于 MySQL 的分表分库，主要是有一个重要考量：分表分库对于第三方依赖较少，业务逻辑灵活可控，它本身并不需要非常复杂的底层处理，也不需要重新做数据库，只是根据不同逻辑使用不同 SQL 语句和数据源而已。

目前市面上主流的分库分表分为两种模式：Proxy模式、Client模式

Proxy模式属于业务无侵入型，直接代理数据库，对于开发者一切都是无感知的，SQL 组合、数据库路由、执行结果合并等功能全部存放在一个代理服务中，比如MyCat、ShardingSphere都对Proxy模式提供了支持

Client模式属于业务侵入型，将分库分表的逻辑放在客户端，客户端需要引入一个jar，比如Sharding-JDBC，架构图如下：

市面上对于分库分表中间件如下：

两种模式的优缺点也很明显：

在落实分表分库解决方案时，我们需要考虑 5 个要点。

1. 分片键如何选择？

针对订单这个业务，其中涉及到以下几个主要的字段：

经过考量，最终选择了user_id作为ShardingKey，为什么呢？

选择user_id作为ShardingKey需要结合业务场景，订单系统中常见的业务：

以上三种业务场景，判断下优先级，C端用户肯定是需要优先满足，因此使用user_id作为ShardingKey

这样在查询时需要将user_id传递过来才能定位到指定库、表

选择字段作为分片键时，我们一般需要考虑三点要求：数据尽量均匀分布在不同表或库、跨库查询操作尽可能少、这个字段的值不会变（这点尤为重要）。

2. 分片的策略是什么？

选择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年数据增长做个判断，预留更多的分片

3. 业务代码如何修改

业务代码的修改这里就不好说了，和自身的业务是强关联。

但是，在这里我想分享一些个人观点。近年来，分表分库操作愈发容易，不过我们需要注意几个要点。

我们已经习惯微服务了，对于特定表的分表分库，其影响面只在该表所在的服务中，如果是一个单体架构的应用做分表分库，那真是伤脑筋。

在互联网架构中，我们基本不使用外键约束。

随着查询分离的流行，后台系统中有很多操作需要跨库查询，导致系统性能非常差，这时分表分库一般会结合查询分离一起操作：先将所有数据在 ES 索引一份，再使用 ES 在后台直接查询数据。如果订单详情数据量很大，还有一个常见做法，即先在 ES 中存储索引字段（作为查询条件的字段），再将详情数据存放在 HBase 中（这个方案我们就不展开了）。

4. 历史数据迁移？

历史数据的迁移非常耗时，有时迁移几天几夜都很正常。而在互联网行业中，别说几天几夜了，就连停机几分钟业务都无法接受，这就要求我们给出一个无缝迁移的解决方案。

还记得讲解查询分离时，我们说过的方案吗？我们再来回顾下，如下图所示：

历史数据迁移时，我们就是采用类似的方案进行历史数据迁移，如下图所示：

此数据迁移方案的基本思路：存量数据直接迁移，增量数据监听 binlog，然后通过 canal 通知迁移程序搬运数据，新的数据库拥有全量数据，且校验通过后逐步切换流量。

数据迁移解决方案详细的步骤如下：

5. 未来的扩容方案是什么？

随着业务的发展，如果原来的分片设计已经无法满足日益增长的数据需求，我们就需要考虑扩容了，扩容方案主要依赖以下两点。

分表分库的不足

分表分库的解决方案讲完了，以上就是业界常用的一些做法，不过此方案仍然存在不足之处。

相关文章