Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

Amazon Aurora MySQL 的最佳实践

本主题提供使用 Amazon Aurora MySQL 数据库集群或向其迁移数据的最佳实践和选项信息。本主题中的信息总结并重申了一些准则和过程，您可以在 管理 Amazon Aurora 数据库集群 中找到这些信息。

确定您连接到的数据库实例

要确定连接到 Aurora MySQL 数据库集群中的哪个数据库实例，请检查 innodb_read_only 全局变量，如以下示例中所示。

SHOW GLOBAL VARIABLES LIKE 'innodb_read_only'; 

innodb_read_only 变量设置为 ON (如果您已连接到读取器数据库实例)。此设置为 OFF (如果您已连接到写入器数据库实例，例如预置集群中的主实例)。

如果要在应用程序代码中添加逻辑以平衡工作负载或确保写入操作使用正确的连接，该方法可能是非常有用的。

Aurora MySQL 性能和扩展的最佳实践

您可以应用以下最佳实践来改进 Aurora MySQL 集群的性能和可扩展性。

使用 T 实例类进行开发和测试

使用 db.t2、db.t3 或 db.t4g 数据库实例类的 Amazon Aurora MySQL 实例最适合不支持长时间运行较高工作负载的应用程序。T 实例旨在提供适度的基准性能，并能够根据您工作负载的需要实现性能的显著突增。它们旨在用于不经常或不持续使用完整 CPU、但偶尔需要突增性能的工作负载。建议仅将 T 数据库实例类用于开发和测试服务器，或其他非生产服务器。有关 T 实例类的更多详细信息，请参阅具爆发能力的实例。

如果您的 Aurora 集群大于 40 TB，请勿使用 T 实例类。当数据库带有大量数据时，管理架构对象的内存开销可能会超过 T 实例的容量。

不要在 Amazon Aurora MySQL T 实例上启用 MySQL 性能架构。如果启用了性能架构，T 实例可能会出现内存不足的情况。

在 Aurora MySQL 数据库集群中使用 T 实例作为数据库实例时，建议执行以下操作：

使用哈希联接优化大型 Aurora MySQL 联接查询

在需要使用 equijoin 联接大量数据时，哈希联接可以提高查询性能。您可以为 Aurora MySQL 启用哈希联接。

哈希联接列可以是任何复杂表达式。在哈希联接列中，您可以使用以下方法比较不同的数据类型：

以下限制适用于 Aurora MySQL 的哈希联接：

启用哈希联接

启用哈希联接：

哈希联接在 Aurora MySQL 版本 3 中原定设置情况下开启，而在 Aurora MySQL 版本 2 中原定设置情况下关闭。以下示例说明了如何为 Aurora MySQL 版本 3 启用哈希联接。您可以先发布语句 select @@optimizer_switch，以了解 SET 参数字符串中存在的其他设置。更新 optimizer_switch 参数中的一个设置不会删除或修改其他设置。

mysql> SET optimizer_switch='block_nested_loop=on';

在使用该设置时，优化程序选择使用基于成本、查询特性和资源可用性的哈希联接。如果成本估算不正确，您可以强制优化程序选择一个哈希联接。为此，请将 MySQL 服务器变量 hash_join_cost_based 设置为 off。以下示例说明了如何强制优化程序选择哈希联接。

mysql> SET optimizer_switch='hash_join_cost_based=off';

优化哈希联接的查询

要确定查询是否可以使用哈希联接，请先使用 EXPLAIN 语句分析查询。EXPLAIN 语句提供有关用于指定查询的执行计划的信息。

在 EXPLAIN 语句的输出中，Extra 列描述执行计划附带的其他信息。如果哈希联接应用于查询中使用的表，该列将包含类似下面的值：

以下示例说明了如何使用 EXPLAIN 查看哈希联接查询的执行计划。

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

在输出中，Hash Join Inner table 是用于构建哈希表的表，Hash Join Outer table 是用于探查哈希表的表。

有关扩展的 EXPLAIN 输出格式的更多信息，请参阅 MySQL 产品文档中的扩展的 EXPLAIN 输出格式。

在 Aurora MySQL 2.08 及更高版本中，您可以使用 SQL 提示来影响查询是否使用哈希联接，以及用于联接的构建和探查端的表。有关详细信息，请参阅 Aurora MySQL 提示。

使用 Amazon Aurora 为 MySQL 数据库扩展读取

您可以将 Amazon Aurora 用于 MySQL 数据库实例，以便利用 Amazon Aurora 的读取扩展功能并为 MySQL 数据库实例扩展读取工作负载。要使用 Aurora 对 MySQL 数据库实例进行读取扩展，请创建 Aurora MySQL 数据库集群并使它成为 MySQL 数据库实例的只读副本。然后连接到 Aurora MySQL 集群以处理读取查询。源数据库可以是 RDS for MySQL 数据库实例或是在 Amazon RDS 外部运行的 MySQL 数据库。有关更多信息，请参阅使用 Amazon Aurora 为 MySQL 数据库扩展读取。

Aurora MySQL 高可用性的最佳实践

您可以应用以下最佳实践来改进 Aurora MySQL 集群的可用性。

使用 Amazon Aurora 实现 MySQL 数据库的灾难恢复

您可以在 MySQL 数据库实例中使用 Amazon Aurora 创建异地备份以进行灾难恢复。要使用 Aurora 实现 MySQL 数据库实例的灾难恢复，请创建 Amazon Aurora 数据库集群并使它成为 MySQL 数据库实例的只读副本。这适用于 RDS for MySQL 数据库实例或是在 Amazon RDS 外部运行的 MySQL 数据库。

有关如何创建 Amazon Aurora MySQL 数据库集群并使它成为 MySQL 数据库实例的只读副本的说明，请遵循 使用 Amazon Aurora 为 MySQL 数据库扩展读取 中的过程。

有关灾难恢复模型的更多信息，请参阅如何为 Amazon Aurora MySQL 集群选择最佳灾难恢复选项。

从 MySQL 迁移到 Amazon Aurora MySQL 并减少停机时间

将数据从支持活动应用程序的 MySQL 数据库导入到 Amazon Aurora MySQL 数据库集群时，您可能希望缩短在迁移时发生服务中断的时间。为此，您可以使用 Amazon Relational Database Service 用户指南的将数据导入到 MySQL 或 MariaDB 数据库实例并减少停机时间中介绍的过程。如果使用非常大的数据库，该步骤可能是非常有用的。您可以使用该步骤最大限度减少通过网络传送到 Amazon 的数据量以降低导入成本。

该过程所列的步骤可将数据库数据的副本传输到 Amazon EC2 实例，并将数据导入到新的 RDS for MySQL 数据库实例。因为 Amazon Aurora 与 MySQL 兼容，所以您可以为目标 Amazon RDS MySQL 数据库实例改用 Amazon Aurora 数据库集群。

避免 Aurora MySQL 数据库实例性能降低、自动重启和失效转移

如果您正在运行繁重的工作负载，或峰值工作负载超出为数据库实例分配的资源，则可能会耗尽运行应用程序和 Aurora 数据库的资源。要获取有关数据库实例的指标，例如 CPU 利用率、内存使用率和使用的数据库连接数，您可以参考 Amazon CloudWatch、性能详情和增强型监控所提供的指标。有关监控数据库实例的更多信息，请参阅 监控 Amazon Aurora 集群中的指标。

如果您的工作负载耗尽了您正在使用的资源，则数据库实例可能会变慢、重新启动，甚至失效转移到另一个数据库实例。为避免这种情况，请监控您的资源利用率，检查数据库实例上运行的工作负载，并在必要时进行优化。如果优化不能改善实例指标和缓解资源耗尽问题，请考虑在达到数据库实例的限制之前对其进行纵向扩展。有关可用数据库实例类及其规格的更多信息，请参阅 Aurora 数据库实例类。

关于 MySQL 功能的建议

以下功能在 Aurora MySQL 中可用于实现 MySQL 兼容性。但是，它们在 Aurora 环境中存在性能、可扩展性、稳定性或兼容性问题。因此，我们建议您在使用这些功能时遵循某些准则。例如，我们不建议使用某些功能进行生产 Aurora 部署。

在 Aurora MySQL 版本 3 中使用多线程复制

默认情况下，当 Aurora MySQL 数据库集群用作二进制日志复制的只读副本时，Aurora 使用单线程复制。

尽管 Aurora MySQL 不禁止多线程复制，但只有 Aurora MySQL 版本 3 支持此功能。

Aurora MySQL 版本 2 继承了 MySQL 中多线程复制方面存在的一些问题。对于该版本，我们建议您不要在生产环境中使用多线程复制。

如果您确实使用多线程复制，我们建议您全面测试任何使用情况。

有关在 Amazon Aurora 中使用复制的更多信息，请参阅 使用 Amazon Aurora 进行复制。有关 Aurora MySQL 版本 3 中的多线程复制的信息，请参阅 多线程二进制日志复制（Aurora MySQL 版本 3 及更高版本）。

使用本机 MySQL 函数调用 Amazon Lambda 函数

我们建议使用原生 MySQL 函数 lambda_sync 和 lambda_async 以调用 Lambda 函数。

如果使用已弃用的 mysql.lambda_async 过程，我们建议您将对 mysql.lambda_async 过程的调用封装在一个存储过程中。您可以从不同的来源调用该存储过程，例如，触发器或客户端代码。这种方法可以帮助您避免出现阻抗不一致问题，并使数据库编程人员更轻松地调用 Lambda 函数。

有关从 Amazon Aurora 中调用 Lambda 函数的更多信息，请参阅 从 Amazon Aurora MySQL 数据库集群中调用 Lambda 函数。

避免将 XA 事务与 Amazon Aurora MySQL 结合使用

我们建议您不要在 Aurora MySQL 中使用扩展架构 (XA) 事务，因为在 XA 处于 PREPARED 状态时，它们可能会造成较长的恢复时间。如果必须在 Aurora MySQL 中使用 XA 事务，请遵循以下最佳实践：

有关将 XA 事务与 MySQL 结合使用的更多信息，请参阅 MySQL 文档中的 XA 事务。

在 DML 语句执行期间保持打开外键

当 foreign_key_checks 变量设置为 0 (off) 时，我们强烈建议您不要运行任何数据定义语言 (DDL) 语句。

如果您需要插入或更新暂时违反外键的行，请执行以下步骤：

此外，请遵循外键约束的这些其他最佳实践：

配置刷新日志缓冲区的频率

在 MySQL 社区版中，为了使事务持久，必须将 InnoDB 日志缓冲区刷新到持久存储。您可以使用 innodb_flush_log_at_trx_commit 参数来配置将日志缓冲区刷新到磁盘的频率。

当您将 innodb_flush_log_at_trx_commit 参数设置为原定设置值 1 时，每次事务提交时都会刷新日志缓冲区。此设置有助于保持数据库符合 ACID 要求。我们建议您保留原定设置 1。

将 innodb_flush_log_at_trx_commit 更改为非原定设置值 0 或 2 有助于减少数据操作语言（DML）延迟，但会牺牲日志记录的持久性。这种缺乏持久性使数据库不符合 ACID 要求。我们建议您的数据库符合 ACID 要求，以避免在服务器重新启动时丢失数据的风险。有关此参数的更多信息，请参阅 MySQL 文档中的 innodb_flush_log_at_trx_commit。

在 Aurora MySQL 中，重做日志处理被卸载到存储层，因此数据库实例上不会发生刷新到日志文件的过程。发出写入操作时，重做日志将从写入器数据库实例直接发送到 Aurora 集群卷。跨网络执行的仅有的写入操作是写入重做日志记录。始终不会从数据库层写入任何页面。

原定设置情况下，在 Aurora MySQL 中，innodb_flush_log_at_trx_commit 参数设置为 1。每个提交事务的线程都要等待来自 Aurora 集群卷的确认。此确认表明该记录和所有先前的重做日志记录均已写入并已达到法定数目。无论是通过自动提交还是显式提交，保留日志记录并达到法定数目都会使事务变得持久。有关 Aurora 存储架构的更多信息，请参阅 Amazon Aurora 存储揭秘。

Aurora MySQL 不会像 MySQL 社区版那样将日志刷新到数据文件。但是，在将重做日志记录写入 Aurora 集群卷时，您可以使用 innodb_flush_log_at_trx_commit 参数放松持久性约束。当您将 innodb_flush_log_at_trx_commit 设置为非原定设置值（0 或 2）时，数据库不会等待有关重做日志记录已写入 Aurora 集群卷的确认。虽然这些设置可以降低客户端的 DML 延迟，但也可能导致在失效转移或重新启动时丢失数据。因此，我们建议您将 innodb_flush_log_at_trx_commit 参数保持设置为原定设置值 1。

虽然在 MySQL 社区版和 Aurora MySQL 中都可能发生数据丢失，但由于每个数据库的架构不同，对于它们的行为也有所不同。这些架构差异可能导致不同程度的数据丢失。要确保您的数据库符合 ACID 要求，请始终将 innodb_flush_log_at_trx_commit 设置为 1。