一般最佳实践

MySQL | PostgreSQL | SQL Server

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

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

实例配置和管理

最佳做法	更多信息
阅读并遵循操作指南，确保您的实例在 Cloud SQL 服务等级协议 (SLA) 的涵盖范围内。
为主实例配置维护期，以控制执行中断性更新的时间。	请参阅维护期。
如果您定期删除并重新创建实例，请在实例 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 控制台中监控两个指标，请参阅指标。
设置 SQL Server 设置，以使它们适用于 Cloud SQL。	请参阅 SQL Server 设置。
根据测试运行情况优化调整实例。	下表列出了适用于测试运行的配置值。 vCPU：`40` 内存：`262144 MB` MAXDOP：`8` 并行成本阈值：`120` tempdb 文件：`8`。已预设定尺寸以防止自动增长。用户数据库文件：在 `64-128` MB 中设置了自动增长。已预设定大小以防止自动增长。存储：提供最佳 IOPS 的 `>= 4TB`
在部署 SQL Server 之前确定 I/O 子系统的容量。	测试各种 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 队列深度。
防止索引碎片化和索引缺失。	根据数据更改频率，重新整理索引或设置重新构建索引的时间表。此外，请设置适当的填充因数以减少碎片化。监控 SQL Server 是否存在可能提升性能的缺失索引。
定期更新统计信息。	如果统计信息已过时，SQL 查询优化器可能会生成欠佳的查询计划。更新统计信息，尤其是在大量数据发生更改之后。请使用查询存储区来监控和优化查询计划欠佳的 SQL Server。
防止数据库文件过大。	请以 MB 为单位设置 `autogrow`，而不是使用百分比，并采用符合要求的增量。此外，在自动增长之前主动管理增长。此外，请确保已启用 Cloud SQL 启用存储空间自动扩容功能，以便在数据库和实例空间不足时，Cloud SQL 可以增加存储空间。
通过至少每周运行一次 `DBCC CHECKDB` 来检测数据库完整性问题。	`DBCC CHECKDB` 检查数据库中所有对象的完整性。通过每周运行 `DBCC CHECKDB`，您可以确保数据库未损坏。 `DBCC CHECKDB` 是一项资源密集型操作，可能会影响实例的性能。请勿在生产服务器上运行 `DBCC CHECKDB`。我们建议您使用以下选项之一，而不是在生产服务器上运行 `DBCC CHECKDB`：克隆数据库并在克隆数据库上运行 `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

数据架构

最佳做法	更多信息
尽可能将大型实例拆分为较小的实例。	如果可能，使用多个较小的 Cloud SQL 实例要优于使用一个大型实例。管理单个大型实例时，会遇到一组较小实例不会发生的难题。
请勿使用太多的数据库表。	确保实例的表数少于 10000 个。太多数据库表可能会影响数据库的升级时间。
数据库排序规则	无论您是安装 SQL Server 的新实例、恢复数据库备份，还是将服务器连接到客户端数据库，都请务必了解语言区域要求、排序顺序以及所使用的数据的大小写和重音敏感度。为服务器、数据库、列或表达式选择排序规则时，您需要为数据分配某些特征。这些特征会影响数据库中许多操作的结果。例如，使用 `ORDER BY` 构建查询时，结果集的排列顺序可能取决于应用于数据库的排序规则，或查询表达式级别的 `COLLATE` 子句中指示的排序规则。详细了解数据库排序规则和 unicode 支持。
查询设计	为获得最佳数据库或查询性能，请确保您未在同一查询中使用大量表（16 个或更多）。
查询监控	查询可能会随时间的变化而降级。请务必监控您的应用和查询性能随时间变化的情况。此类降级的一个原因是哈希释放。递归哈希联接或哈希释放会导致服务器性能下降。如果您在跟踪记录中看到许多哈希警告事件，请更新要联接的列的统计信息。详细了解哈希释放。

应用实现

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

数据导入和导出

最佳做法	更多信息
加快小型实例的导入。	对于小型实例，您可以临时增加实例的 CPU 和 RAM，以提高导入大型数据集时的性能。
如果您要导出数据以导入到 Cloud SQL 中，请务必采用正确的过程。	请参阅从外部代管式数据库服务器导出数据。

备份与恢复

最佳做法	更多信息
使用适当的 Cloud SQL 功能保护您的数据。	备份和导出是提供数据冗余和保护的方法。它们各自防范不同的情形，并在强大的数据保护策略中相互补充。备份属于轻量级；通过备份，可以将实例上的数据恢复到进行备份时的状态。但是，备份也存在一些限制。如果您删除实例，备份也会被删除。您无法备份单个数据库或表。并且如果实例所在的区域不可用，则无法通过对应备份恢复实例，即使在可用区域中也不行。导出需要较长时间才能创建，因为在 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 Storage 中创建了可用于重新创建数据的外部文件。如果您删除实例，导出不会受影响。此外，您可以只导出单个数据库甚至表，具体取决于您选择的导出格式。

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

保护您的实例和备份免遭意外删除。

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

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

SQL Server 设置

对于 Cloud SQL，建议使用某些 SQL Server 设置。以下主题介绍了一些建议。

全局配置设置

设置建议

max worker threads 保留默认值 0。此设置根据 CPU 数定义 SQL Server 可用的线程数。SQL Server 引擎在启动时会自动计算该值。

max server memory (MB)

如果您没有为此设置指定值，那么随着时间推移，SQL Server 会随意消耗内存，直到消耗的内存量达到 100%。如果 Cloud SQL for SQL Server 实例的内存用量过高，您可能会遇到性能问题。如需详细了解 SQL Server 的内存用量，请参阅监控内存用量。

我们建议您使用以下公式设置
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 百分比：

实例层级 (MB)	最大服务器内存 (MB)	百分比（总计）
3840	1440	37
4096	1632	39
5792	2912	50
8192	4704	57
11584	7248	62
16384	10848	66
23168	16800	72
32768	25200	76
46336	37072	80
65568	53888	82
92704	77648	83
131136	111248	84
185440	158784	85
262272	226000	86
370880	321056	86
524544	455488	86
741792	645600	87

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

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 Server 数据库性能，请根据以下建议设置 SQL Server 设置。

设置	建议
`cost threshold for parallelism`	这是 SQL 优化器使用并行执行查询时的阈值。默认值 `5` 可能会导致过多查询并行运行，因而增加并行线程上的数据库等待时间。为了减少此类争用，请提高该值。当 `maxdop` 设置为 `1` 时，系统会忽略该值。
`max degree of parallelism (MAXDOP)`	为了减少由并行性引起的数据库等待，请根据与可用逻辑处理器数量相关的特定建议调整此值。如果将此选项设置为 1，请仔细衡量性能。
`optimize for ad hoc workloads`	避免在方案缓存中包含大量一次性方案。如需提高包含许多一次性临时批次的工作负载的方案缓存效率，请将此选项设置为 `1`。
`tempdb`	预设 `tempdb` 的大小，使其无需自动增长。 `tempdb` 中所有文件的大小都应相同，并且设置了相同的文件增长。 `tempdb` 争用的数据库等待类型显示为 `PAGELATCH_UP`。如要减少争用，请添加更多文件。如果处理器数量小于或等于 8，请使用与逻辑处理器数量相同的文件。如果处理器数量大于 8，请使用 8 个数据文件。如果争用仍继续存在，请将文件数量增加 4 倍，直到不再出现争用。

根据您的工作负载，您可能还需要修改以下设置。

设置	建议
`Close Cursor on Commit Enabled`	默认值为 `off`，表示在您提交事务时，游标不会自动关闭。
`Default Cursor`	此选项用于控制 T-SQL 代码中使用的游标的范围。如果您更改此设置，请评估应用代码是否存在任何不利影响。
`Page Verify`	通过此选项，SQL Server 可以在数据库页面写入磁盘之前计算其校验和，并将校验和存储在页面标头中。当再次读取页面时，会重新计算校验和以验证页面的完整性。建议值为 `checksum`。
`Parameterization`	默认值为 `simple`。简单参数化允许 SQL Server 将查询中的字面量值替换为参数。Microsoft 提供了有关如何更改此值以及将其与方案指南搭配使用的准则。

要保留的数据库设置

为获得最佳 SQL Server 数据库性能，请保留以下 SQL Server 设置的默认值。

设置	要保留的默认值
`Auto Close`	`False`。此设置开启后会打开和关闭连接，并在每次连接后刷新过程。这可能会导致经常访问的数据库性能下降。
`Auto Shrink`	`False`。开启此设置可能会导致数据库和索引碎片化以及其他性能问题，其中一些问题在此 SQL Server 博客中进行了讨论。
`Date Correlation Optimization Enabled`	`False`。如果启用此设置，优化器可查找和优化两个相关表中的日期之间的关系。在 SQL Server 中跟踪此操作会产生一些性能开销。
`Legacy Cardinality Estimation`	`False`。在某些情况下，启用此设置时，SQL Server 无法准确计算基数。
`Parameter Sniffing`	`ON`。从数据库表嗅探参数有助于创建可重复使用的执行计划。如果表具有不均匀分布的数据，则生成的执行计划可能会导致性能问题。对于此类数据，请使用查询存储区中的其他选项，而不是修改此设置。
`Query Optimizer Fixes`	`False`。启用此设置可能会影响 SQL Server 基数 Estimator 的性能。如果您选择启用它，请进行测试以确保没有查询回归。
`Auto Create Statistics`	`True`。通过此选项，SQL Server 可以创建单列统计信息，从而提高查询计划基数的估算值。
`Auto Update Statistics`	`True`。通过此选项，SQL Server 可以使用基于表基数的重新编译阈值更新过时的统计信息。
`Auto Update Statistics Asynchronously`	`False`。启用此选项后，它将指示 SQL 查询优化器使用过时统计信息执行当前查询，同时异步更新统计信息以使将来的工作负载受益。但是，如果您预计频繁执行的查询具有可预测的响应时间，或者您的应用在等待统计信息更新时频繁遇到客户端请求超时，请考虑启用此选项并停用 `Auto Update Statistics`。
`Target Recovery Time (Seconds)`	`60`。此设置通过以更高或更低的频率将脏页从缓冲区池刷新到磁盘来设置数据库恢复时间的上限。对于较高的事务性工作负载，此设置的较低值加上接近最大值的存储 IOPS 可能会导致性能瓶颈。

跟踪标志设置

SQL Server 中的跟踪标志用于在 SQL Server 中设置某些特征，更改 SQL Server 数据库的行为或调试问题。

某些 SQL Server 跟踪标志在 Cloud SQL 中受支持，可以使用数据库标志进行设置。推荐的设置如下所示。

跟踪标志	推荐
`1204`	`Yes`，用于造成大量死锁的工作负载密集型服务器除外。返回相关资源、参与死锁的锁类型以及当前受影响的命令。
`1222`	`Yes`，用于造成大量死锁的工作负载密集型服务器除外。
`1224`	`No`。这会导致内存用量增加，并造成数据库内存压力。
`2528`	`No`。并行检查对象是默认设置，并且是推荐的设置。并行度由数据库引擎自动计算。
`3205`	`No`。用于备份的磁带驱动器是 Cloud SQL for SQL Server 的一项功能。
`3226`	`No`，除非您需要频繁备份，例如 TLOG 备份。
`3625`	`No`。由于根账号没有系统管理员访问权限，因此它可能无法查看所有错误消息。
`4199`	`No`。这会影响基数 Estimator，并可能导致查询回归。
`4616`	`No`。此限制会降低应用角色的安全性。需要根据应用要求对其进行验证。
`7806`	`Yes`。如果数据库服务器无响应，则专用管理员连接 (DAC) 可能是建立连接以进行诊断的唯一方式。

后续步骤

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