使用 PlanetScale 构建可扩展的 MySQL 数据库

May 19, 2026 · 3 min read

如果你正在使用 MySQL 构建全栈应用，迟早会遇到一个熟悉的问题：本地数据库在开发阶段运行良好，但自行运行生产级 MySQL 服务器意味着要处理备份、可用性、连接限制以及可能导致应用下线的 schema 迁移。PlanetScale 是一个托管的 MySQL 平台，旨在消除大部分运维负担——但它不仅仅是托管版的 MySQL。本文将解释它的独特之处、其核心工作流如何运作，以及在什么情况下真正适合使用它。

核心要点

PlanetScale 是一个基于 Vitess 构建的托管 MySQL 兼容平台，提供原生 MySQL 所不具备的横向扩展能力和连接池管理。
数据库分支为 schema 变更引入了类似 Git 的工作流，通过部署请求和非阻塞迁移确保生产环境持续在线。
外键在未分片的数据库上可正常使用，但分片配置则需要在应用层强制执行引用完整性。
PlanetScale 在 serverless 应用和需要安全、可审查的 schema 变更的团队中表现出色——但对于预算紧张的小项目可能过于重量级。

PlanetScale 究竟是什么（以及它与原生 MySQL 的区别）

PlanetScale 是一个托管的 MySQL 兼容数据库平台，基于 Vitess 构建。Vitess 是最初在 YouTube 开发的开源数据库集群系统，用于将 MySQL 横向扩展到多台服务器。

这个区别很重要。PlanetScale 并不是原生的 MySQL。你的应用使用标准的 MySQL 连接字符串连接到它，大多数你编写的 SQL 都能正常运行。但在底层，Vitess 添加了原生 MySQL 所没有的能力：大规模连接池、横向分片支持以及非阻塞 schema 变更。

对于大多数前端和全栈开发者来说，实际意义是：PlanetScale 处理了那些原本需要专职数据库管理员才能搞定的基础设施复杂性。

Vitess 如何实现横向扩展

单台 MySQL 服务器存在硬性限制——连接数、写入吞吐量，以及表能增长到多大才会让查询变慢。Vitess 通过作为代理层来解决这个问题，将查询分发到多个底层 MySQL 实例上。

实际上，这意味着 PlanetScale 能够优雅地处理连接峰值——这在 serverless 环境中尤其有用，例如 Cloudflare Workers 或 Vercel Functions 等函数可能会同时打开数千个连接。Vitess 在内部对这些连接进行池化处理，避免数据库被压垮。

需要澄清的是：这并不是消除所有限制的神奇横向扩展。分片本身也带来了复杂性，对大多数中小型应用而言，你并不需要它。但这种架构意味着 PlanetScale 可以随着应用一起成长，而无需后期重新更换平台。

数据库分支和部署请求工作流

PlanetScale 最对开发者友好的功能之一是数据库分支——一种类似 Git 的 schema 变更工作流。

实际操作如下：

你的生产数据库运行在受保护的生产分支上。PlanetScale 鼓励通过部署请求和安全迁移来变更 schema，而不是直接在生产分支上应用变更。
你创建一个开发分支——schema 的独立副本——在其中进行变更和测试。
准备就绪后，你打开一个部署请求，将 schema 变更合并到生产环境。
PlanetScale 使用非阻塞 schema 迁移来应用这些变更，这意味着你的生产数据库在整个过程中保持在线。

这个工作流消除了一个常见的生产事故源头：在大表上运行 ALTER TABLE，导致写入被锁定数分钟甚至数小时。在 PlanetScale 上，这种风险已经在平台层面得到了管理。

外键、分片和 MySQL 兼容性考量

PlanetScale 在未分片的数据库上支持外键约束，这覆盖了大多数使用场景。如果你启用了分片，跨分片表的外键则不被支持——这是 Vitess 分布数据方式的根本性限制。对于分片配置，引用完整性需要在应用层强制执行。

如果你使用 Prisma，可以配置 relationMode = "prisma" 来模拟关系，而不依赖数据库级别的外键，并手动在外键列上添加索引以避免慢查询。

何时适合使用 PlanetScale——何时不适合

PlanetScale 在以下场景非常合适：

你正在构建一个需要扩展到单个数据库服务器之外的应用。
你希望进行非阻塞的 schema 变更，又不想自行管理相关工具。
你工作在连接模式不可预测的 serverless 环境中。
你希望为数据库 schema 变更建立结构化、可审查的工作流。

以下情况则值得重新考虑：

你的应用规模较小，不太可能超出 AWS RDS 或其他竞争服务提供的单个托管 MySQL 实例的能力。
你的预算紧张——PlanetScale 的定价反映的是企业级平台的定位。
你严重依赖 Vitess 没有完全支持的 MySQL 特性。

连接你的应用

PlanetScale 为每个分支提供标准的 MySQL 连接字符串。你可以将其存储为环境变量，然后使用任何 MySQL 兼容的驱动或 ORM 进行连接：

DATABASE_URL='mysql://username:password@aws.connect.psdb.cloud/your-database?sslaccept=strict'

它适用于 Prisma、Drizzle ORM、原生 mysql2 连接以及大多数其他 MySQL 客户端。对于 serverless 环境，PlanetScale 还提供了一个基于 HTTP 的 serverless 驱动，完全避免了持久 TCP 连接。

结论

PlanetScale 为全栈开发者提供了一个生产级、可扩展的 MySQL 平台，并配备了开发者工作流——数据库分支、部署请求、非阻塞迁移——降低了发布 schema 变更的风险。它并非适合每一个项目，且其 Vitess 基础意味着你使用的是 MySQL 兼容而非完全相同的行为。但对于规模和 schema 安全性至关重要的应用，它消除了大量原本会落在你团队肩上的运维复杂性。

常见问题

可以。PlanetScale 暴露的是标准的 MySQL 连接字符串，因此任何 MySQL 兼容的客户端都能使用，包括 Prisma、Drizzle ORM、TypeORM、Sequelize 和 mysql2 等原生驱动。唯一需要注意的是，由于 PlanetScale 运行在 Vitess 之上，一些高级 MySQL 特性的行为可能会有所不同。对于 serverless 工作负载，PlanetScale 还提供了基于 HTTP 的驱动，避免了持久 TCP 连接。

启用分片时，Vitess 将数据分布在多个 MySQL 实例上，因此引用另一个分片上某行的外键无法在数据库层面高效地强制执行。这是横向扩展的架构性权衡。在未分片的数据库上，外键正常工作。对于分片配置，你需要在应用代码或 ORM 层强制执行引用完整性。

PlanetScale 使用 Vitess 在后台应用 schema 变更，不会锁定原始表。它创建表的影子副本，在副本上应用变更，复制数据，然后原子地切换表。这意味着在大表上添加列或索引等操作无需停机或写入锁定即可完成，相比直接运行 ALTER TABLE 是一个巨大的改进。

可以适合，但其定价和功能集面向的是受益于扩展、分支和安全迁移的生产应用。对于流量可预测的小型副业项目，AWS RDS、DigitalOcean 或类似服务商提供的基础托管 MySQL 实例可能更具成本效益。当你真正需要其工作流或扩展特性时，再选择 PlanetScale。

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.