一般最佳实践

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

Google Cloud 控制台中的实例状态不会反映操作是否正在运行。绿色对勾标记仅表示实例处于 RUNNABLE 状态。如需查看操作是否正在运行，请转到操作标签页，然后检查最近操作的状态。

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

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

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

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

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

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

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

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

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

• vCPU：40
• 内存：262144 MB
• MAXDOP：8
• 并行成本阈值：120
• tempdb 文件：8。已预设定尺寸以防止自动增长。
• 用户数据库文件：在 64-128 MB 中设置了自动增长。已预设定大小以防止自动增长。
• 存储：提供最佳 IOPS 的 >= 4TB

测试各种 I/O 类型和大小。来自 SQL Server 的永久性磁盘存储空间的 I/O 大小会影响 IOPS 和吞吐量。当 SQL Server 工作负载达到 IOPS 限制或吞吐量限制时，它会受到限制。Cloud SQL 中使用的存储类型是 PD SSD，它适用于高性能企业级工作负载。

按如下方式自定义虚拟机以最大限度地提高性能：

• 大小为 4 TB 或更大的磁盘可提供更高的吞吐量和 IOPS。
• 较高的 vCPU 可提供更高的 IOPS 和吞吐量。使用更高的 vCPU 时，请监控 DB 等待并行性，其等待时长可能也会增加。
• 为了获得最佳性能，请并行发出 I/O 以实现更高的 I/O 队列深度。

请以 MB 为单位设置 autogrow，而不是使用百分比，并采用符合要求的增量。此外，在自动增长之前主动管理增长。

此外，请确保已启用 Cloud SQL 启用存储空间自动扩容功能，以便在数据库和实例空间不足时，Cloud SQL 可以增加存储空间。

• 克隆数据库并在克隆数据库上运行 DBCC CHECKDB。
• 将备份恢复到另一个实例，然后在已恢复实例的数据库上运行 DBCC CHECKDB。 如需详细了解如何恢复实例，请参阅恢复实例。

使用以下代码段在数据库上运行 DBCC CHECKDB：

• （推荐）使用 EXTENDED_LOGICAL_CHECKS 运行 DBCC CHECKDB。 这是一项全面但占用更多资源的检查。

        USE DATABASE_NAME
        DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
        DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
        

• 使用 PHYSICAL_ONLY 运行 DBCC CHECKDB：

        USE DATABASE_NAME
        DBCC CHECKDB WITH PHYSICAL_ONLY,
        NO_INFOMSGS, ALL_ERRORMSGS
        

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

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

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

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

在企业或标准 SQL Server 实例上使用导出备份功能时，请避免创建 GZ 归档文件，因为它会尝试压缩已通过 SQL Server 以原生方式压缩的备份。

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

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

此标志会限制 Cloud SQL 可为其内部池分配的内存量。

如果您未为此标志设置值，Cloud SQL 会根据实例的 RAM 大小自动管理此值。此外，如果您调整实例大小，Cloud SQL 会自动调整此标志的值，以满足我们对新实例大小的建议。

我们强烈建议您不要为实例指定此标志的值。如果您将此值设置为高于 80%，则可能会因内存不足问题而导致不稳定、性能下降和数据库崩溃。

如果您希望管理此标志的值，请手动进行设置。因此，Cloud SQL 会停用自动管理功能。如果您要调整实例大小，不妨重新考虑此值，使其与新大小的建议值相符。

我们建议您使用以下公式设置
max server memory 数据库标志：

• 为操作系统和代理预留 1.4 GB 内存。
• 如果服务器上的 RAM 小于或等于 16 GB，则为每 4 GB RAM 预留 1 GB 内存。
• 如果服务器上的 RAM 超过 16 GB，则预留 4 GB 内存，并为超过 16 GB 的每 8 GB RAM 预留 1 GB 内存。

例如，如果实例的 RAM 为 104 GB
(106496 MB)，则预留：

• 1.4 GB 内存，用于操作系统和代理
• 4 GB 内存，因为 104 GB 大于 16 GB
• 11 GB 内存，因为有 88 GB RAM 大于 16 GB (104-16=88)，而 88 除以 8 等于 11

在此示例中，您必须预留 16.4 GB 内存。因此对于此标志的值，请指定 89702 MB
[(104-16.4) * 1024 = 89702]。

下表列出了适用于一些受欢迎虚拟机 (VM) 层级的推荐值和总 RAM 百分比：

如需监控实例的内存用量，请使用以下指标：

• database/memory/usage
• database/sqlserver/memory/buffer_cache_hit_ratio
• database/sqlserver/memory/memory_grants_pending
• database/sqlserver/memory/page_life_expectancy

如需了解详情，请参阅监控 Cloud SQL 实例。

这是 SQL 优化器使用并行执行查询时的阈值。默认值 5 可能会导致过多查询并行运行，因而增加并行线程上的数据库等待时间。为了减少此类争用，请提高该值。

当 maxdop 设置为 1 时，系统会忽略该值。

为了减少由并行性引起的数据库等待，请根据与可用逻辑处理器数量相关的特定建议调整此值。如果将此选项设置为 1，请仔细衡量性能。

避免在方案缓存中包含大量一次性方案。如需提高包含许多一次性临时批次的工作负载的方案缓存效率，请将此选项设置为 1。

预设 tempdb 的大小，使其无需自动增长。 tempdb 中所有文件的大小都应相同，并且设置了相同的文件增长。

tempdb 争用的数据库等待类型显示为 PAGELATCH_UP。如要减少争用，请添加更多文件。

如果处理器数量小于或等于 8，请使用与逻辑处理器数量相同的文件。如果处理器数量大于 8，请使用 8 个数据文件。如果争用仍继续存在，请将文件数量增加 4 倍，直到不再出现争用。

但是，如果您预计频繁执行的查询具有可预测的响应时间，或者您的应用在等待统计信息更新时频繁遇到客户端请求超时，请考虑启用此选项并停用 Auto Update Statistics。