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 索引的联接查询

Aurora MySQL 可以使用异步键预取（AKP）功能来提高跨索引联接表的查询的性能。该功能通过预测运行查询所需的行 (JOIN 查询需要使用批处理键访问 (BKA) 联接算法和多区间读 (MRR) 优化功能) 来提高性能。有关 BKA 和 MRR 的更多信息，请参阅 MySQL 文档中的块嵌套循环和批处理键访问联接和多区间读优化。

要利用 AKP 功能，查询必须使用 BKA 和 MRR。通常，当查询的 JOIN 子句使用二级索引并且还需要主索引中的一些列时，会出现此类查询。例如，如果 JOIN 子句表示小型外部表和大型内部表之间的索引值的 equijoin，并且索引在大型表中具有高选择性，则可以使用 AKP。AKP 与 BKA 和 MRR 协作，在计算 JOIN 子句期间执行二级索引到主索引的查找。AKP 标识计算 JOIN 子句期间运行查询所需的行。之后，在运行查询之前，它使用后台线程异步将包含这些行的页加载到内存中。

AKP 适用于 Aurora MySQL 版本 2.10 及更高版本和版本 3。有关 Aurora MySQL 版本的更多信息，请参阅Amazon Aurora MySQL 的数据库引擎更新。

启用异步键预取

您可以将 MySQL 服务器变量 aurora_use_key_prefetch 设置为 on 以启用 AKP 功能。默认情况下，该值设置为 on。不过，在您也启用 BKA 联接算法并禁用基于成本的 MRR 功能之前，无法启用 AKP。为此，您必须为 MySQL 服务器变量 optimizer_switch 设置以下值：

目前，您只能在会话级别设置这些值。以下示例说明了如何设置这些值以通过执行 SET 语句来为当前会话启用 AKP。

mysql> set @@session.aurora_use_key_prefetch=on;
mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

同样，您可以使用 SET 语句为当前会话禁用 AKP 和 BKA 联接算法并重新启用基于成本的 MRR 功能，如以下示例中所示。

mysql> set @@session.aurora_use_key_prefetch=off;
mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

有关 batched_key_access 和 mrr_cost_based 优化程序开关的更多信息，请参阅 MySQL 文档中的 可切换的优化。

优化异步键预取的查询

您可以确认查询是否能利用 AKP 功能。为此，请使用 EXPLAIN 语句来分析查询，然后再运行查询。EXPLAIN 语句提供有关用于指定查询的执行计划的信息。

在 EXPLAIN 语句的输出中，Extra 列描述执行计划附带的其他信息。如果 AKP 功能应用于查询中使用的表，则此列包含下列值之一：

以下示例说明如何使用 EXPLAIN 来查看可利用 AKP 的查询的执行计划。

mysql> explain select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

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

使用哈希联接优化大型 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 数据库的读取。

优化时间戳操作

当系统变量 time_zone 的值设置为 SYSTEM 时，每个需要时区计算的 MySQL 函数调用都会进行系统库调用。当您运行在高并发条件下返回或更改此类 TIMESTAMP 值的 SQL 语句时，可能会遇到延迟、锁定争用和 CPU 使用率增加的情况。有关更多信息，请参阅 MySQL 文档中的 time_zone。

为避免这种行为，我们建议您将 time_zone 数据库集群参数的值更改为 UTC。有关更多信息，请参阅 在 Amazon Aurora 中修改数据库集群参数组中的参数。

虽然 time_zone 参数是动态的（不需要重新启动数据库服务器），但新值仅用于新连接。为确保更新所有连接以使用新的 time_zone 值，我们建议您在更新数据库集群参数后回收应用程序连接。