Amazon RDS 的最佳实践

了解使用 Amazon RDS 的最佳实践。随着新的最佳实践的确定，我们将持续更新此部分。

Amazon RDS 基本操作指导方针

以下是使用 Amazon RDS 时每个人都应遵循的基本操作指导方针。请注意，Amazon RDS 服务等级协议要求您遵循以下指导方针：

数据库实例 RAM 建议

Amazon RDS 性能最佳实践是分配足够的 RAM，以便您的工作集几乎完全驻留在内存中。工作集是经常在实例上使用的数据和索引。使用数据库实例的次数越多，工作集的增长量就越大。

若要确定您的工作集是否几乎完全位于内存中，请在数据库实例加载期间检查 ReadIOPS 指标 (使用 Amazon CloudWatch)。ReadIOPS 的值应是一个较小且稳定的值。在某些情况下，将数据库实例类纵向扩展为具有更多 RAM 的类会导致 ReadIOPS 大幅降低。在这些情况下，您的工作集几乎不完全在内存中。继续向上扩展直至 ReadIOPS 不再在扩展操作后大幅降低，否则 ReadIOPS 将降低至非常小的数量。有关监控数据库实例的指标的信息，请参阅在 Amazon RDS 控制台中查看指标。

AWS 数据库驱动程序

推荐使用 AWS 驱动程序套件来建立应用程序连接。借助这些驱动程序可显著缩短切换和故障转移时间，并支持使用 AWS Secrets Manager、AWS Identity and Access Management（IAM）和联合身份进行身份验证。AWS 驱动程序依靠监控数据库实例状态和了解实例拓扑，来确定新的写入器。这种方法将切换和故障转移时间缩短到几秒钟，而开源驱动程序的切换和故障转移时间则为几十秒。

随着新服务功能的推出，使用 AWS 驱动程序套件可为这些服务功能提供内置支持。

有关更多信息，请参阅 使用 AWS 驱动程序连接到数据库实例。

使用增强监控来确定操作系统问题

启用增强监测后，Amazon RDS 可提供运行数据库实例的操作系统 (OS) 的实时指标。您可以使用控制台查看数据库实例的指标。您还可以在您选择的监控系统中通过 Amazon CloudWatch Logs 使用增强型监控 JSON 输出。有关增强监控的更多信息，请参阅 使用增强监控来监控操作系统指标。

使用指标确定性能问题

要确定资源不足和其他常见瓶颈导致的性能问题，您可以监控可用于 Amazon RDS 数据库实例的指标。

查看性能指标

您应定期监控性能指标以查看各种时间范围内的平均值、最大值和最小值。通过这样做，您可以确定性能下降的时间。您还可以针对特定指标阈值设置 Amazon CloudWatch 警报，以便在达到这些阈值时向您发出警报。

要排除性能问题，了解系统的基准性能十分重要。当您设置数据库实例并在典型工作负载下运行该实例时，请捕获所有性能指标的平均值、最大值和最小值。按多个不同的间隔（例如，一小时、24 小时、一周、两周）执行此操作。这使您能够了解正常运行状况。这有助于将操作的峰值时间与非峰值时间进行比较。您随后可以利用这些信息确定性能何时降到标准水平以下。

如果使用多可用区数据库集群，则监控写入器数据库实例上的最新事务与读取器数据库实例上最新应用的事务之间的时间差异。这种差异称为副本滞后。有关更多信息，请参阅 副本滞后和多可用区数据库集群。

您可以在 Performance Insights 控制面板中查看组合的 Performance Insights 和 CloudWatch 指标，并监控您的数据库实例。为使用此监控视图，必须为您的数据库实例开启 Performance Insights。有关监控视图的信息，请参阅使用性能详情控制面板查看组合指标。

您可以创建特定时间段的性能分析报告，并查看已确定的见解和解决问题的建议。有关更多信息，请参阅在性能详情中创建性能分析报告。

还可以使用 CLI 或 API 查看性能指标。有关更多信息，请参阅“在 Amazon RDS 控制台中查看指标”。

警报将显示在 CloudWatch 警报部分中。

评估性能指标

数据库实例有一些不同类别的指标，确定可接受的值的方式取决于具体的指标。

有关可用的性能指标的各个更详细的说明，请参阅使用 Amazon CloudWatch 监控 Amazon RDS 指标。

一般而言，性能指标的可接受值取决于您的基准性能以及应用程序执行的操作。应调查相对于基准性能的一致或趋势性变化。有关特定类型指标的建议如下：

对于与性能指标有关的问题，改善性能的第一步是优化最常使用和成本最高昂的查询。对它们进行优化，看看这样做能否减轻系统资源承受的压力。有关更多信息，请参阅 优化查询。

如果您的查询经优化后，问题仍然存在，请考虑升级您的 Amazon RDS 数据库实例类。您可以将其升级为具有更多与问题相关的资源（CPU、RAM、磁盘空间、网络带宽，I/O 容量）的实例类。

优化查询

提高数据库实例性能的最佳方式之一是优化最常使用和占用资源最多的查询。在这里，您可以优化它们以降低它们的运行成本。有关改进查询的信息，请使用以下资源：

使用 MySQL 的最佳实践

MySQL 数据库中的表大小和表的数量都会影响性能。

表大小

通常，操作系统对文件大小的约束决定了 MySQL 数据库的有效最大表大小。因此，限制通常不是由内部 MySQL 约束决定的。

在 MySQL 数据库实例中，请避免数据库中的表增长得过大。虽然一般存储限制为 64 TiB，但预置的存储限制将 MySQL 表文件的最大大小限制为 16 TiB。请对大型表进行分区，以将文件大小限制在 16 TiB 以内。此方法还可以提高性能并缩短恢复时间。有关更多信息，请参阅“Amazon RDS 中的 MySQL 文件大小限制”。

大小非常大的表（大于 100 GB）可能会对读取和写入（包括 DML 语句，尤其是 DDL 语句）的性能有负面影响。大型表上的索引可以显著提高选择性能，但也可能降低 DML 语句的性能。DDL 语句（例如 ALTER TABLE）在处理大型表时性能会显著降低，因为在某些情况下，这些操作可能会完全重建表。这些 DDL 语句可能会在操作期间锁定表。

MySQL 进行读取和写入操作所需的内存量取决于操作中涉及的表。最佳做法是至少有足够的 RAM 来保存主动使用的表的索引。要查找数据库中十个最大的表和索引，请使用以下查询：

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

表的数量

底层文件系统可能对表示表的文件的数量有限制。但是，MySQL 对表的数量没有限制。尽管如此，MySQL InnoDB 存储引擎中的表总数还是可能导致性能下降，无论这些表的大小如何。要限制操作系统的影响，您可以将表拆分到同一 MySQL 数据库实例中的多个数据库。这样做可能会限制目录中文件的数量，但不能解决整体问题。

当由于表的数量过多（超过 1 万个）而出现性能下降时，这种性能下降是由 MySQL 处理存储文件（包括打开和关闭存储文件）造成的。要解决此问题，可以提高 table_open_cache 和 table_definition_cache 参数的大小。但是，提高这些参数的值可能会显著增加 MySQL 使用的内存量，甚至可能会占用所有可用内存。有关更多信息，请参阅 MySQL 文档中的 MySQL 如何打开和关闭表。

此外，表的数量过多会显著影响 MySQL 的启动时间。干净关机和重启以及崩溃恢复都可能受到影响，尤其是在 MySQL 8.0 之前的版本中。

我们建议数据库实例的所有数据库中表的总数少于 10,000。有关 MySQL 数据库中大量表的使用案例，请参阅 MySQL 8.0 中的一百万个表。

存储引擎

Amazon RDS for MySQL 时间点还原和快照还原功能要求使用崩溃恢复存储引擎。仅 InnoDB 存储引擎支持这些功能。尽管 MySQL 支持功能不同的多种存储引擎，但并非所有引擎都为崩溃恢复和数据持久性而进行了优化。例如，MyISAM 存储引擎不支持可靠的崩溃恢复，并且可能使时间点还原或快照还原无法按预期工作。这可能导致在崩溃后重新启动 MySQL 时丢失或损坏数据。

InnoDB 是 Amazon RDS 上的 MySQL 数据库实例的推荐和支持的存储引擎。InnoDB 实例还可迁移到 Aurora，而 MyISAM 实例无法迁移。但是，如果您需要高强度的全文搜索功能，MyISAM 的效果比 InnoDB 更好。如果您仍然选择对 Amazon RDS 使用 MyISAM，遵循 使用不支持的 MySQL 存储引擎进行自动备份 中概述的步骤可能在某些情况下对执行快照恢复功能会有所帮助。

如果要将现有 MyISAM 表转换为 InnoDB 表，可以使用 MySQL 文档的 Converting Tables from MyISAM to InnoDB 中概述的过程。MyISAM 和 InnoDB 各有优缺点，所以请在执行转换前充分评估转换可能对您的应用程序造成的影响。

此外，Amazon RDS for MySQL 当前不支持联合存储引擎。

使用 MariaDB 的最佳实践

MariaDB 数据库中的表大小和表的数量都会影响性能。

表大小

通常，操作系统对文件大小的约束决定了 MariaDB 数据库的有效最大表大小。因此，限制通常不是由内部 MariaDB 约束决定的。

在 MariaDB 数据库实例中，请避免数据库中的表增长得过大。虽然一般存储限制为 64 TiB，但预置的存储限制将 MariaDB 表文件的最大大小限制为 16 TiB。请对大型表进行分区，以将文件大小限制在 16 TiB 以内。此方法还可以提高性能并缩短恢复时间。

大小非常大的表（大于 100 GB）可能会对读取和写入（包括 DML 语句，尤其是 DDL 语句）的性能有负面影响。大型表上的索引可以显著提高选择性能，但也可能降低 DML 语句的性能。DDL 语句（例如 ALTER TABLE）在处理大型表时性能会显著降低，因为在某些情况下，这些操作可能会完全重建表。这些 DDL 语句可能会在操作期间锁定表。

MariaDB 进行读取和写入操作所需的内存量取决于操作中涉及的表。最佳做法是至少有足够的 RAM 来保存主动使用的表的索引。要查找数据库中十个最大的表和索引，请使用以下查询：

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

表的数量

底层文件系统可能对表示表的文件的数量有限制。但是，MariaDB 对表的数量没有限制。尽管如此，MariaDB InnoDB 存储引擎中的表总数还是可能导致性能下降，无论这些表的大小如何。要限制操作系统的影响，您可以将表拆分到同一 MariaDB 数据库实例中的多个数据库。这样做可能会限制目录中文件的数量，但不能解决整体问题。

当由于表的数量较多（超过 10,000）而出现性能下降时，这种性能下降是由 MariaDB 处理存储文件造成的。这项工作包括 MariaDB 打开和关闭存储文件。要解决此问题，可以提高 table_open_cache 和 table_definition_cache 参数的大小。但是，提高这些参数的值可能会显著增加 MariaDB 使用的内存量。它甚至可能会占用所有可用内存。有关详细信息，请参阅 MariaDB 文档中的优化 table_open_cache 。

此外，表的数量过多会显著影响 MariaDB 的启动时间。干净关机和重启以及崩溃恢复都可能受到影响。我们建议数据库实例中所有数据库中表的总数少于一万。

存储引擎

Amazon RDS for MariaDB 时间点还原和快照还原功能要求使用崩溃恢复存储引擎。尽管 MariaDB 支持功能不同的多种存储引擎，但并非所有引擎都针对崩溃恢复和数据耐久性而进行了优化。例如，尽管 Aria 是 MyISAM 的崩溃安全替代，但它仍可能使时间点还原或快照还原无法按预期工作。这可能导致在崩溃后重新启动 MariaDB 时丢失或损坏数据。InnoDB 是 Amazon RDS 上的 MariaDB 数据库实例的推荐和支持的存储引擎。如果您仍然选择对 Amazon RDS 使用 Aria，遵循使用不支持的 MariaDB 存储引擎进行自动备份中概述的步骤可能在某些情况下对执行快照恢复功能会有所帮助。

如果要将现有 MyISAM 表转换为 InnoDB 表，可以使用 MariaDB 文档的 Converting Tables from MyISAM to InnoDB 中概述的过程。MyISAM 和 InnoDB 各有优缺点，所以请在执行转换前充分评估转换可能对您的应用程序造成的影响。

使用 Oracle 的最佳实践

有关使用 Amazon RDS for Oracle 的最佳实践信息，请参阅在 Amazon Web Services 中运行 Oracle 数据库的最佳实践。

2020 年AWS虚拟研讨会包括关于在 Amazon RDS 上运行生产 Oracle 数据库的演示。可在此处获取演示视频：

使用 PostgreSQL 的最佳实践

在以下两种重要情况下，您可改善 RDS for PostgreSQL 的性能：一种情况是在将数据加载到数据库实例中时。另一种情况是使用 PostgreSQL autovacuum 功能时。以下各节涵盖了我们针对以下情况建议的一些实例。

有关如何 Amazon RDS 实施其他常见 PostgreSQL DBA 任务的信息，请参阅 Amazon RDS for PostgreSQL 的数据库管理员常见任务。

将数据加载到 PostgreSQL 数据库实例中

在将数据加载到 Amazon RDS for PostgreSQL 数据库实例中时，修改数据库实例设置和数据库参数组值。将它们设置为允许以最高效的方式将数据导入数据库实例中。

对数据库实例设置进行以下修改：

修改数据库参数组以包括以下设置。此外，测试参数设置以找到对数据库实例最高效的设置。

将 pg_dump -Fc (压缩) 或 pg_restore -j (并行) 命令与这些设置结合使用。

加载操作完成后，将数据库实例和数据库参数恢复为正常设置。

使用 PostgreSQL Autovacuum 功能

PostgreSQL 数据库的 autovacuum 功能是我们强烈向您推荐的一项功能，您可使用此功能保持 PostgreSQL 数据库实例正常运行。Autovacuum 自动执行 VACUUM 和 ANALYZE 命令。使用 autovacuum 是 PostgreSQL 所需的而不是 Amazon RDS 强制的，并且使用此功能对于获得良好性能是至关重要的。原定设置情况下，为所有新的 Amazon RDS for PostgreSQL 数据库实例启用此功能，并将适当地设置相关的配置参数。

您的数据库管理员需要知道和了解此维护操作。有关 autovacuum 的 PostgreSQL 文档，请参阅Autovacuum 守护程序。

Autovacuum 不是一个“不占用资源”的操作，但它将会在后台运行并尽可能地在让位于用户操作。启用后，autovacuum 将检查是否有包含大量更新的或删除的元组的表。它还可防止因事务 ID 重叠导致丢失非常旧的数据。有关更多信息，请参阅防止事务 ID 重叠故障。

Autovacuum 不应被视为是一种开销较高的操作 (可减少此类操作以获得更佳性能)。相反，如果未运行 autovacuum，则更新和删除速度较快的表的性能将随时间推移而快速降低。

autovacuum 参数确定 autovacuum 运行的时间和难度。autovacuum_vacuum_threshold 和 autovacuum_vacuum_scale_factor 参数确定 autovacuum 运行的时间。autovacuum_max_workers、autovacuum_nap_time、autovacuum_cost_limit 和 autovacuum_cost_delay 参数确定 autovacuum 运行的难度。有关 autovacuum、其运行时间和所需参数的更多信息，请参阅 PostgreSQL 文档中的日常清理。

以下查询显示名为 table1 的表中的“不活动”元祖数：

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

查询结果将与下面类似：

relname | n_dead_tup | last_vacuum | last_autovacuum
---------+------------+-------------+-----------------
 tasks   |   81430522 |             |
(1 row) 

Amazon RDS for PostgreSQL 最佳实践视频

2020 年AWS re:Invent 会议包含了有关新功能和在 Amazon RDS 上使用 PostgreSQL 的最佳实践的演示。可在此处获取演示视频：

使用 SQL Server 的最佳实践

利用 SQL Server 数据库实例实现多可用区部署的最佳实践包括：

在使用 SQL Server 的多可用区部署时，请记住，Amazon RDS 会为您实例上的所有 SQL Server 数据库创建副本。如果不希望特定数据库具有辅助副本，请设置不使用这些数据库的多可用区的单独数据库实例。

Amazon RDS for SQL Server 最佳实践视频

2019 年AWS re:Invent 会议包含了有关新功能和在 Amazon RDS 上使用 SQL Server 的最佳实践的演示。可在此处获取演示视频：

使用数据库参数组

我们建议，在将参数组更改应用于生产数据库实例前，您应当在测试数据库实例上试验数据库参数组更改。在数据库参数组内不恰当地设置数据库引擎参数可能会产生意外的不利影响，包括性能降低和系统不稳定。修改数据库引擎参数时应始终保持谨慎，并且在修改数据库参数组前要备份数据库实例。

有关备份数据库实例的信息，请参阅备份、还原和导出数据。

自动创建数据库实例的最佳实践

Amazon RDS最佳实践是使用数据库引擎的首选次要版本创建数据库实例。您可以使用 AWS CLI、Amazon RDS API 或 AWS CloudFormation 自动创建数据库实例。使用这些方法时，您只能指定主要版本，Amazon RDS 随后将自动创建采用首选次要版本的实例。例如，如果 PostgreSQL 12.5 是首选次要版本，并且您使用 create-db-instance 指定版本 12，则数据库实例的版本将使用版本 12.5。

要确定首选次要版本，您可以使用 describe-db-engine-versions 选项运行 --default-only 命令，如以下示例所示。

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

有关以编程方式创建数据库实例的信息，请参阅以下资源：

Amazon RDS 新特征视频

2023 年 AWS re:Invent 会议包含了有关新的 Amazon RDS 特征的演示。可在此处获取演示视频：