一般最佳实践

本页面介绍了一些最佳做法，遵循这些做法可从 Cloud SQL 获得最佳的性能、耐用性和可用性。

如果您的 Cloud SQL 实例出现问题，请在排查问题时查看以下内容：

实例配置和管理

最佳做法 更多信息
阅读并遵循操作指南，确保您的实例在 Cloud SQL 服务等级协议 (SLA) 的涵盖范围内。
为主实例配置维护期，以控制执行中断性更新的时间。 请参阅维护期。
对于频繁读取的工作负载，请添加只读副本以从主实例分流流量。 （可选）您可以使用负载均衡器（例如 HAProxy）来管理发送到副本的流量。
如果您定期删除并重新创建实例，请在实例 ID 中使用时间戳以增加新实例 ID 可用的可能性。
在先前操作完成之前，请勿启动管理操作。

Cloud SQL 实例在完成先前的操作之前不接受新的操作请求。如果您试图提前启动新操作，则操作请求将失败。这也包括实例重启在内。

Google Cloud 控制台中的实例状态不会反映操作是否正在运行。绿色对勾标记仅表示实例处于 RUNNABLE 状态。如需查看操作是否正在运行，请转到操作标签页，然后检查最近操作的状态。
配置存储空间以支持重要的数据库维护。

如果停用了启用存储空间自动扩容功能实例设置，或者启用了存储空间自动扩容上限，请确保您至少有 20% 的可用空间以支持 Cloud SQL 可能执行的重要数据库维护操作。

如果您希望在可用磁盘空间低于 20% 时收到提醒，请为磁盘利用率指标创建基于指标的提醒政策，并设置高于阈值的阈值位置和 .8 的阈值。如需了解详情，请参阅创建基于指标的提醒政策。
防止 CPU 利用率过高。

您可以在 Google Cloud 控制台的“实例详情”页面上查看实例正在使用的可用 CPU 的百分比。如需了解详情，请参阅指标。您还可以使用创建指标阈值提醒政策，监控 CPU 使用率并在达到指定的阈值时收到提醒。

为了避免利用率过高，您可以增加实例的 CPU 数。更改 CPU 需要重启实例。如果实例的 CPU 数已达到上限，则必须将数据库分片到多个实例。
避免内存耗尽。

在查找内存耗尽迹象时，应主要使用 usage 指标。为避免发生内存不足的错误，我们建议将此指标保持在 90% 以下。

您还可以使用 total_usage 指标来观察 Cloud SQL 实例正在使用的可用内存百分比，包括数据库容器使用的内存以及操作系统缓存。

通过观察这两个指标之间的差异，您可以确定进程使用的内存量与操作系统缓存使用的内存量。您可以将此缓存中的内存改作他用。

如需预测内存不足问题，请检查这两个指标并一起解读。如果这些指标看起来较高，则表示实例可能内存不足。这可能是因为自定义配置和/或工作负载的实例规模不足。

扩缩 Cloud SQL 实例以增加其内存大小。 更改实例的内存大小需要重启实例。 如果实例已达到内存大小上限，则必须将数据库分片到多个实例。如需详细了解如何在 Google Cloud 控制台中监控两个指标，请参阅指标。
确保实例具有最佳事务 ID。

您可以通过将 Resource Type 设置为 Cloud SQL Database 并将 Metric 设置为 Percentage of instance's transaction IDs consumed，在 Google Cloud 控制台中的 Metrics Explorer 页面上查看实例的事务 ID 使用情况。如需了解详情，请参阅使用 Metrics Explorer 创建图表。

调整和监控数据库实例有助于减少或避免与 vacuum 相关的问题。监控实例的事务 ID 使用情况，并根据实例上的工作负载启用和调整 autovacuum 参数。如需了解详情，请参阅克服事务 ID (TXID) 回卷保护。

数据架构

最佳做法 更多信息
尽可能将大型实例拆分为较小的实例。 如果可能，使用多个较小的 Cloud SQL 实例要优于使用一个大型实例。 管理单个大型实例时，会遇到一组较小实例不会发生的难题。
请勿使用太多的数据库表。

确保实例的表数少于 10000 个。太多数据库表可能会影响数据库的升级时间。

应用实现

最佳做法 更多信息
采用最佳连接管理做法，例如连接池和指数退避算法。 使用这些方法会改善应用对资源的使用，并帮助您保持在 Cloud SQL 连接限制内。如需了解详情和代码示例，请参阅管理数据库连接。
测试应用对维护更新的响应情况，这可能在维护期间随时发生。 尝试自助维护以模拟维护更新。在维护期间，实例在短时间内变得不可用，并且现有连接会被丢弃。通过测试维护发布，您可以更好地了解应用处理计划性维护的方式以及系统恢复的速度。
测试应用对故障切换的响应情况，这可能随时发生。 您可以使用 Google Cloud 控制台、gcloud CLI 或 API 手动启动故障切换。请参阅启动故障切换。
避免大型事务。 保持事务小而简短。如果需要进行大型数据库更新，将其分为几个较小的事务执行，而不是通过一个大型事务。
如果您使用的是 Cloud SQL Auth 代理，请确保使用最新版本。 请参阅保持 Cloud SQL Auth 代理为最新版本。

数据导入和导出

最佳做法 更多信息
使用无服务器导出功能。 无服务器导出会将导出操作分流到临时实例，使主实例可以继续处理查询，并以正常的性能执行操作。数据导出操作完成后，临时实例会被自动删除。
加快小型实例的导入。 对于小型实例，您可以临时增加实例的 CPU 和 RAM，以提高导入大型数据集时的性能。
如果您要导出数据以导入到 Cloud SQL 中，请务必采用正确的过程。 请参阅从外部代管式数据库服务器导出数据。

备份与恢复

最佳做法 更多信息
使用适当的 Cloud SQL 功能保护您的数据。

备份、时间点恢复和导出是提供数据冗余和保护的方法。它们各自防范不同的情形，并在强大的数据保护策略中相互补充。

备份属于轻量级；通过备份，可以将实例上的数据恢复到进行备份时的状态。但是，备份也存在一些限制。如果您删除实例，备份也会被删除。您无法备份单个数据库或表。并且如果实例所在的区域不可用，则无法通过对应备份恢复实例，即使在可用区域中也不行。

借助时间点恢复，您可以将实例恢复到特定的时间点。例如，如果错误导致数据丢失，您可以将数据库恢复到错误发生前的状态。时间点恢复始终会创建一个新实例；您不能对现有实例执行时间点恢复。

导出需要较长时间才能创建，因为在 Cloud Storage 中创建了可用于重新创建数据的外部文件。如果您删除实例，导出不会受影响。此外，您可以只导出单个数据库甚至表，具体取决于您选择的导出格式。

调整实例大小以考虑事务（二进制）日志保留量。 对数据库的高写入活动可能会生成大量事务（二进制）日志，这可能会占用大量磁盘空间，并可能会导致用于已启用自动增加存储的实例的磁盘用量增加。建议调整实例存储的大小以考虑事务日志保留量。
保护您的实例和备份免遭意外删除。

默认情况下，您在 Google Cloud 控制台中或通过 Terraform 创建的 Cloud SQL 实例可以防止意外删除。

使用 Cloud SQL 中的导出功能导出数据以提供额外保护。将 Cloud Scheduler 与 REST API 搭配使用以自动执行导出管理。对于更高级的场景，将 Cloud Scheduler 与 Cloud Run functions 搭配使用以实现自动化。

调整和监控

调整和监控数据库实例有助于减少或避免与 vacuum 有关的问题。

VACUUM 操作具有不同的变体，这些变体具有不同的锁定级别：标准 VACUUM 和 VACUUM FULL。VACUUM FULL 选项可以收回更多磁盘空间，但只会锁定表并且运行缓慢。请改用标准形式的 VACUUM，它可以与生产数据库操作并行运行。使用 VACUUM 操作时，SELECT, INSERT, UPDATE, and DELETE 等命令会继续正常运行。您无法在表清空时使用 ALTER TABLE 等命令修改表的定义。

以下提供了一些建议，可能有助于缩短完成 VACUUM 操作所需的时间：

  • 增加系统内存和 maintenance_work_mem。这可以在每次迭代中批处理更多元组，并尽快完成工作。请注意，autovacuum 运行时，此内存可能会被分配高达 autovacuum_max_workers 倍，因此切勿将默认值设置过高。
  • VACUUM 操作会生成大量预写式日志 (WAL) 记录。如果可以减少 WAL 记录的数量（例如，不对实例配置副本），则操作将更快完成。
  • 如果由于没有元组被冻结，表达到了 20 亿个事务 ID 上限，请尝试减少单用户模式下完成的工作量。一种可以采用的方法是设置 vacuum_freeze_min_age=1,000,000,000（允许的最大值，远远超出默认值 5000 万）。这一新值可将冻结的元组数减少高达两倍。
  • PostgreSQL 12.0 及更高版本支持清理和 VACUUM 操作，而无需清理索引条目。这一点至关重要，因为清理索引需要完整的索引扫描；如果存在多个索引，则总时间取决于索引大小。
  • 索引越大，索引扫描所用时间就越长，因此最好使用 INDEX_CLEANUP OFF 快速清理和冻结表数据。12.0 之前的 PostgreSQL 版本需要调整索引的数量。也就是说，如果存在非关键索引，那么删除 NON-CRITICAL 索引可能有助于加快 vacuum 操作的速度。

后续步骤

如需详细了解数据库引擎的一般做法，请参阅：