给 MySQL 数据库分片的三个意想不到的好处

发表于： 2025年9月13日 2025年9月13日
分类： mysql
标签： mysql

企业通常通过为数据库分片来扩展系统，而这是一台服务器即使不断增加资源也无法实现的水平扩展方法。
当你对数据库进行水平分片时，实际上是将数据分成多个部分，并将其分散到不同的数据库服务器上。听起来，添加更多服务器意味着你的团队需要承担更多维护工作，以及你的预算需要支付更多费用，而回报则是你的系统能够处理更多的数据库流量。虽然在某些情况下这确实有一定道理，但往往事情不会这么简单，其中还有一些不那么明显的好处。
在本文中，我们将探讨为数据库分片除了提高吞吐量之外，还能为企业带来的三个关键好处。

减少故障影响

架构基础设施时，有一句经典谚语：“两个等于一个，一个等于零。”
这句话的含义是，你永远不应该只有单一的组件，因为那样会带来单点故障的风险。这一点对数据库来说同样适用，甚至更为重要，因为数据库是应用程序的核心部分。在典型的 MySQL 环境中，如果数据库服务器出现故障，整个应用程序也会随之瘫痪。
而在分片环境中，这种故障域实际上得到了分散。
想象一个场景：你根据客户 ID 的范围对数据库进行分片。
一个带有五个客户分片的数据库架构图
如果分片 A 出现故障，可能会让客户 1-5 的日子很不好过，但其他分片实际上仍在线并且可以正常提供服务。由于故障影响更加局限，你的公司团队在与客户沟通以及从故障中恢复时，受到的冲击会相对较小。
同时，不考虑由于故障造成的收入损失时，分片也能将这种损失降到最低。

提高维护任务效率

MySQL 环境越大，管理起来就越困难。
比如备份一个 1TB 的数据库。备份过程不仅耗时，而且可能显著影响数据库响应查询的速度。现在我们将这个同样的数据库拆分为一个分片环境，其中的数据均匀分布在五个分片上，与上面的示例相似。
备份五个 200GB 的数据库不仅更快，如果需要从这些数据库中恢复数据，也会更高效。
备份只是分片简化数据库管理的众多例子之一。
架构迁移（Schema Migration）也是一个可以提高效率的任务。例如，在 PlanetScale 上，你合并一个部署请求（Deploy Request）时，我们会在目标数据库分支上创建一个新表，将更新后的架构版本应用到新表，并同步“实时表”中的数据到这个“幽灵表”（Ghost Table）。一旦更改合并完成，旧表会被删除，而“幽灵表”会成为新的生产表。
使用以上的分片示例，在较小的数据库上并行执行这些操作将显著减少完成所需的时间。

可能反而能节省开支

我知道此刻你的脑海可能会冒出这样的想法：“分片怎么可能节省开支？不是还要添加更多服务器吗？”
我们先来看看**垂直扩展**的成本问题。当你每次配置一个服务器时，需要分配足够的资源（如 CPU、内存、IOPS）来运行你的服务，同时考虑到需要额外的资源冗余以应对使用高峰。随着应用规模的扩大，最终你的服务器资源会达到上限，需要进一步增加资源及更多的冗余。
这种循环不断重复，导致你始终支付超过实际使用需求的费用。
现在想象一个世界，你的数据库已经分片到五台服务器上，如前文所示。
当负载超过当前服务器资源的承载能力时，你可以添加一台与现有配置相同的新服务器，并将负载均匀地重新分配到这些服务器上。虽然仍然需要一定冗余，但比起垂直扩展方式所需的冗余资源显著减少。此外，由于添加的服务器具有相同的规格，总成本的增加更加线性和可预测，这一点你的财务团队一定会很感兴趣。
一张比较水平扩展与垂直扩展方法之间可扩展性与成本的图表。
分片节省开支的另一种方式是利用云基础设施中的商品级磁盘。
随着数据库使用量的增长，底层存储的 IOPS（每秒输入输出操作数）需求也随之增加。低成本的虚拟磁盘通常有一个固定的 IOPS 限制，超过限制后你可能需要选择更昂贵的选项。如果未提前规划，这种额外成本可能悄然增加。
而通过将数据库分片到多个低成本磁盘上，可以避免更高成本磁盘的额外费用，从而节省开支。