# 与 MySQL 8.0 兼容的 Aurora MySQL 版本 3
您可以使用 Aurora MySQL 版本 3 来获得最新的 MySQL 兼容功能、性能增强功能和错误修复。接下来，您可以了解与 MySQL 8.0 兼容的 Aurora MySQL 版本 3。您可以了解如何将集群和应用程序升级到 Aurora MySQL 版本 3。
一些 Aurora 功能（例如 Aurora Serverless v2）需要 Aurora MySQL 版本 3。
**Topics**
+ [MySQL 8.0 社群版中的功能](#AuroraMySQL.8.0-features-community)
+ [Aurora MySQL 版本 3 是 Aurora MySQL Serverless v2 的先决条件](#AuroraMySQL.serverless-v2-8.0-prereq)
+ [Aurora MySQL 版本 3 的发布说明](#AuroraMySQL.mysql80-bugs-fixed)
+ [新的并行查询优化](#AuroraMySQL.8.0-features-pq)
+ [进行优化以缩短数据库重启时间](#ReducedRestartTime)
+ [Aurora MySQL 版本 3 中的新临时表行为](ams3-temptable-behavior.md)
+ [比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3](AuroraMySQL.Compare-v2-v3.md)
+ [比较 Aurora MySQL 版本 3 和 MySQL 8.0 社群版](AuroraMySQL.Compare-80-v3.md)
+ [升级到 Aurora MySQL 版本 3](AuroraMySQL.mysql80-upgrade-procedure.md)
## MySQL 8.0 社群版中的功能
Aurora MySQL 版本 3 的初始版本与 MySQL 8.0.23 社群版兼容。MySQL 8.0 引入了几项新功能，包括以下功能：
+ 原子数据定义语言（DDL）支持。有关更多信息，请参阅 [原子数据定义语言（DDL）支持](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl)。
+ JSON 函数。有关使用信息，请参阅 *MySQL 参考手册*中的 [JSON 函数](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html)。
+ 窗口函数。有关使用信息，请参阅 *MySQL 参考手册*中的 [Window 函数](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html)。
+ 使用 `WITH` 子句的公用表表达式 (CTE)。有关使用信息，请参阅 *MySQL 参考手册*中的 [WITH（公用表表达式）](https://dev.mysql.com/doc/refman/8.0/en/with.html)。
+ `ALTER TABLE` 语句的优化 `ADD COLUMN` 和 `RENAME COLUMN` 子句。这些优化被称为“即时 DDL”。Aurora MySQL 版本 3 与社群 MySQL 即时 DDL 功能兼容。未使用以前的 Aurora 快速 DDL 功能。有关即时 DDL 的使用信息，请参阅 [即时 DDL（Aurora MySQL 版本 3）](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl)。
+ 降序、功能性和不可见的索引。有关使用信息，请参阅 *MySQL 参考手册*中的[不可见索引](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html)、[降序索引](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html)和 [CREATE INDEX 语句](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts)。
+ 通过 SQL 语句控制的基于角色的权限。有关更改权限模型的更多信息，请参阅 [基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。
+ 带有 `SELECT ... FOR SHARE` 语句的 `NOWAIT` 和 `SKIP LOCKED` 子句。这些子句避免了等待其他事务释放行锁。有关使用信息，请参阅 *MySQL 参考手册*中的[锁定读取](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html)。
+ 改进二进制日志 (binlog) 复制。有关 Aurora MySQL 的详细信息，请参阅 [二进制日志复制](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog)。特别是，您可以执行筛选的复制。有关筛选复制的使用信息，请参阅 *MySQL 参考手册*中的[服务器如何评估复制筛选规则](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)。
+ 提示。一些 MySQL 8.0 兼容的提示已被向后移植到 Aurora MySQL 版本 2。有关将提示用于 Aurora MySQL 的信息，请参阅 [Aurora MySQL 提示](AuroraMySQL.Reference.Hints.md)。有关社群 MySQL 8.0 中的完整提示列表，请参阅 *MySQL 参考手册*中的[优化程序提示](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)。
有关添加到 MySQL 8.0 社群版的功能的完整列表，请参阅博客文章 [MySQL 8.0 中的完整新功能列表](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/)。
Aurora MySQL 版本 3 还包括对包容性语言的关键字的更改，从社群 MySQL 8.0.26 向后移植。有关更改的详细信息，请参阅 [Aurora MySQL 版本 3 的包容性语言更改](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language)。
## Aurora MySQL 版本 3 是 Aurora MySQL Serverless v2 的先决条件
Aurora MySQL 版本 3 是 Aurora MySQL Serverless v2 集群中所有数据库实例的先决条件。Aurora MySQL Serverless v2 包括对数据库集群中的读取器实例的支持，并包括对 Aurora MySQL Serverless v1 不可用的其他 Aurora 功能。与 Aurora MySQL Serverless v1 相比，它还具有更快、更细粒度的扩展。
## Aurora MySQL 版本 3 的发布说明
有关所有 Aurora MySQL 版本 3 发布的发布说明，请参阅《Aurora MySQL 发布说明》中的 [Amazon Aurora MySQL 版本 3 的数据库引擎更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)**。
## 新的并行查询优化
Aurora 并行查询优化现在适用于更多的 SQL 操作：
+ 并行查询现在适用于包含数据类型 `TEXT`、`BLOB`、`JSON`、`GEOMETRY` 和 `VARCHAR` 以及超过 768 个字节的 `CHAR` 的表。
+ 并行查询可以优化涉及分区表的查询。
+ 并行查询可以优化涉及选择列表中聚合函数调用的查询和 `HAVING` 子句。
有关这些增强功能的更多信息，请参阅 [将并行查询集群升级到 Aurora MySQL 版本 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2)。有关 Aurora 并行查询的一般信息，请参阅 [Amazon Aurora MySQL 的并行查询](aurora-mysql-parallel-query.md)。
## 进行优化以缩短数据库重启时间
在计划内和计划外停机期间，您的 Aurora MySQL 数据库集群都必须具有高可用性。
数据库管理员需要偶尔进行数据库维护。此维护包括数据库修补、升级、需要手动重启的数据库参数修改、执行故障转移以缩短实例类更改所花费的时间等。这些计划内操作需要停机。
但是，停机也可能由计划外操作引起，例如由于底层硬件故障或数据库资源限制而导致的意外故障转移。所有这些计划内和计划外操作都会导致数据库重启。
在 Aurora MySQL 3.05 及更高版本中，我们引入了缩短数据库重启时间的优化措施。与未进行优化相比，这些优化措施可减少多达 65% 的停机时间，并且在重启后数据库工作负载的中断也会减少。
在数据库启动期间，会初始化许多内部内存组件。其中最大的是 [InnoDB 缓冲池](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)，在 Aurora MySQL 中，该缓冲池默认为实例内存大小的 75％。我们经测试发现，初始化时间与 InnoDB 缓冲池的大小成正比，因此会随着数据库实例类的大小而扩展。在此初始化阶段，数据库无法接受连接，这会导致重启期间的停机时间更长。Aurora MySQL 快速重启的第一阶段优化了缓冲池初始化，这将会缩短数据库初始化的时间，从而缩短总体重启时间。
有关更多详细信息，请参阅博客[借助 Amazon Aurora MySQL 数据库重启时间优化减少停机时间](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/)。
# Aurora MySQL 版本 3 中的新临时表行为
Aurora MySQL 版本 3 处理临时表的方式与早期的 Aurora MySQL 版本不同。这种新行为继承自 MySQL 8.0 社群版。使用 Aurora MySQL 版本 3 可以创建两种类型的临时表：
+ 内部（或*隐式*）临时表 – 由 Aurora MySQL 引擎创建，以处理诸如对聚合、派生表或公用表表达式 (CTE) 进行排序等操作。
+ 用户创建的（或*显式*）临时表 – 使用 `CREATE TEMPORARY TABLE` 语句时由 Aurora MySQL 引擎创建。
对于 Aurora 读取器数据库实例上的内部和用户创建的临时表，还有其他注意事项。我们将在以下各节中讨论这些变化。
**Topics**
+ [内部（隐式）临时表的存储引擎](#ams3-temptable-behavior-engine)
+ [限制内部内存中临时表的大小](#ams3-temptable-behavior-limit)
+ [缓解 Aurora 副本上内部临时表的完整性问题](#ams3-temptable-behavior-mitigate)
+ [优化 Aurora MySQL 数据库实例上的 temptable\$1max\$1mmap 参数](#ams-optimize-temptable_max_mmap)
+ [读取器数据库实例上用户创建的（显式）临时表](#ams3-temptable-behavior.user)
+ [临时表创建错误和缓解](#ams3-temptable-behavior.errors)
## 内部（隐式）临时表的存储引擎
在生成中间结果集时，Aurora MySQL 最初尝试写入内存中临时表。这可能不成功，原因是数据类型不兼容或配置了限制。如果是这样，临时表将转换为磁盘上的临时表，而不是保留在内存中。有关这方面的更多信息，请参阅 MySQL 文档中的[在 MySQL 中使用内部临时表](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html)。
在 Aurora MySQL 版本 3 中，内部临时表的工作方式与早期的 Aurora MySQL 版本不同。现在，您不必针对此类临时表在 InnoDB 与 MyISAM 存储引擎之间进行选择，而是在 `TempTable` 与 `MEMORY` 存储引擎之间进行选择。
使用 `TempTable` 存储引擎，您可以另外选择如何处理某些数据。受影响的数据溢出了保存数据库实例的所有内部临时表的内存池。
这些选择可能会影响生成大量临时数据的查询的性能，例如，在大型表上执行诸如 `GROUP BY` 之类的聚合操作。
**提示**
如果您的工作负载包括生成内部临时表的查询，请通过运行基准测试和监控与性能相关的指标来确认应用程序如何执行此更改。
在某些情况下，临时数据量适合 `TempTable` 内存池或者只有少量溢出内存池。在这些情况下，我们建议将 `TempTable` 设置用于内部临时表和内存映射文件以保存任何溢出数据。此设置是原定设置。
`TempTable` 存储引擎为默认引擎。`TempTable` 对使用此引擎的所有临时表使用公用内存池，而不是每个表的最大内存限制。此内存池的大小由 [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) 参数指定。对于具有 16 GiB 或更多内存的数据库实例，其默认设置为 1 GiB；而对于内存小于 16 GiB 的数据库实例，其默认设置为 16 MB。内存池的大小会影响会话级别的内存消耗。
在某些情况下，当您使用 `TempTable` 存储引擎时，临时数据可能会超过内存池的大小。如果是这样，Aurora MySQL 会使用辅助机制存储溢出数据。
您可以设置 [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 参数来选择数据是溢出到内存映射的临时文件，还是磁盘上的 InnoDB 内部临时表。这些溢出机制的不同数据格式和溢出标准可能会影响查询性能。他们通过影响写入磁盘的数据量和对磁盘存储吞吐量的需求来实现这一目标。
Aurora MySQL 版本 3 通过以下方式存储溢出数据：
+ 在写入器数据库实例上，溢出到 InnoDB 内部临时表或内存映射临时文件的数据驻留在实例上的本地存储中。
+ 在读取器数据库实例上，溢出数据始终驻留在本地存储上的内存映射临时文件中。
只读实例无法在 Aurora 集群卷上存储任何数据。
与内部临时表相关的配置参数对集群中的写入器和读取器实例的应用方式不同：
+ 在读取器实例上，Aurora MySQL 始终使用 `TempTable` 存储引擎。
+ 对于写入器和读取器实例，`temptable_max_mmap` 的大小都默认设置为 1GiB，无论数据库实例内存大小如何。可以在写入器实例和读取器实例上调整此值。
+ 将 `temptable_max_mmap` 设置为 `0` 可禁止在写入器实例上使用内存映射的临时文件。
+ 您无法在读取器实例上将 `temptable_max_mmap` 设置为 `0`。
**注意**
建议您不要使用 [temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap) 参数。它已被弃用，预计将在将来的 MySQL 版本中删除对它的支持。
## 限制内部内存中临时表的大小
如[内部（隐式）临时表的存储引擎](#ams3-temptable-behavior-engine)中所述，可以通过使用 [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) 和 [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 设置来全局控制临时表资源。
还可以使用 [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) 数据库参数，来限制任何单个内部内存中临时表的大小。此限制旨在防止各个查询消耗过量的全局临时表资源，这可能会影响需要这些资源的并发查询的性能。
`tmp_table_size` 参数定义了 Aurora MySQL 版本 3 中由 `MEMORY` 存储引擎创建的临时表的最大大小。
在 Aurora MySQL 版本 3.04 及更高版本中，`tmp_table_size` 还定义了当 `aurora_tmptable_enable_per_table_limit` 数据库参数设置为 `ON` 时，`TempTable` 存储引擎创建的临时表的最大大小。默认情况下，此行为处于禁用状态（`OFF`），这与 Aurora MySQL 版本 3.03 及更低版本中的行为相同。
+ 当 `aurora_tmptable_enable_per_table_limit` 为 `OFF` 时，不考虑将 `tmp_table_size` 用于由 `TempTable` 存储引擎创建的内部内存中临时表。
但是，全局 `TempTable` 资源限制仍然适用。当达到全局 `TempTable` 资源限制时，Aurora MySQL 会出现以下行为：
+ 写入器数据库实例 – Aurora MySQL 自动将内存中临时表转换为 InnoDB 磁盘上临时表。
+ 读取器数据库实例 - 查询结束时出现错误。
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
+ 当 `aurora_tmptable_enable_per_table_limit` 为 `ON` 时，如果达到 `tmp_table_size` 限制，Aurora MySQL 会出现以下行为：
+ 写入器数据库实例 – Aurora MySQL 自动将内存中临时表转换为 InnoDB 磁盘上临时表。
+ 读取器数据库实例 - 查询结束时出现错误。
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
全局 `TempTable` 资源限制和每个表的限制都适用于这种情况。
**注意**
当 [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) 设置为 `MEMORY` 时，`aurora_tmptable_enable_per_table_limit` 参数不起作用。在这种情况下，内存中临时表的最大大小由 [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) 或 [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size) 值定义，以较小者为准。
以下示例显示了写入器和读取器数据库实例的 `aurora_tmptable_enable_per_table_limit` 参数的行为。
**Example `aurora_tmptable_enable_per_table_limit` 设置为 `OFF` 的写入器数据库实例**
内存中临时表未转换为 InnoDB 磁盘上临时表。
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 0 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (13.99 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example `aurora_tmptable_enable_per_table_limit` 设置为 `ON` 的写入器数据库实例**
内存中临时表转换为 InnoDB 磁盘上临时表。
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 0 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
+---------+
| max(n) |
+---------+
| 6000000 |
+---------+
1 row in set (4.10 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 1 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example `aurora_tmptable_enable_per_table_limit` 设置为 `OFF` 的读取器数据库实例**
查询完成时没有出现错误，因为 `tmp_table_size` 不适用，并且尚未达到全局 `TempTable` 资源限制。
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (14.05 sec)
```
**Example `aurora_tmptable_enable_per_table_limit` 设置为 `OFF` 的读取器数据库实例**
此查询达到全局 TempTable 资源限制，`aurora_tmptable_enable_per_table_limit` 设置为 OFF。查询结束时读取器实例上出现错误。
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.01 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full
```
**Example `aurora_tmptable_enable_per_table_limit` 设置为 `ON` 的读取器数据库实例**
如果达到 `tmp_table_size` 限制，查询结束时出现错误。
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 1 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full
```
## 缓解 Aurora 副本上内部临时表的完整性问题
为避免临时表的大小限制问题，请将 `temptable_max_ram` 和 `temptable_max_mmap` 参数设置为可以满足工作负载要求的组合值。
设置 `temptable_max_ram` 参数的值时要小心。将该值设置为过高会减少数据库实例上的可用内存，这可能会导致内存不足的情况。监控数据库实例上的平均可用内存。然后，确定 `temptable_max_ram` 的适当值，以便实例上仍剩余合理的可用内存量。有关更多信息，请参阅 [Amazon Aurora 中的可用内存问题](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory)。
监控本地存储的大小和临时表空间占用情况也很重要。可以使用 `FreeLocalStorage` Amazon CloudWatch 指标监控特定数据库实例可用的临时存储，如 [Amazon Aurora 的 Amazon CloudWatch 指标](Aurora.AuroraMonitoring.Metrics.md)中所述。
**注意**
当 `aurora_tmptable_enable_per_table_limit` 参数设置为 `ON` 时，此过程不起作用。有关更多信息，请参阅[限制内部内存中临时表的大小](#ams3-temptable-behavior-limit)。
**Example 1**
您知道临时表增长到 20 GiB 的累计大小。您希望将内存中的临时表设置为 2 GiB，而在磁盘上增长到最大 20 GiB。
将 `temptable_max_ram` 设置为 **2,147,483,648**，将 `temptable_max_mmap` 设置为 **21,474,836,480**。这些值以字节为单位。
这些参数设置可确保临时表可以增长到累计 22 GiB 的总大小。
**Example 2**
您当前的实例大小为 16xlarge 或更大。您不知道可能需要的临时表的总大小。您希望能够在内存中使用多达 4 GiB，并在磁盘上使用最大的可用存储大小。
将 `temptable_max_ram` 设置为 **4,294,967,296**，将 `temptable_max_mmap` 设置为 **1,099,511,627,776**。这些值以字节为单位。
在此，您将 `temptable_max_mmap` 设置为 1 TiB，这小于 16xlarge Aurora 数据库实例上的最大本地存储 1.2 TiB。
在较小的实例大小上，调整 `temptable_max_mmap` 的值，以使它不会填满可用的本地存储。例如，2xlarge 实例只有 160 GiB 的本地存储可用。因此，我们建议将该值设置为小于 160 GiB。有关数据库实例大小的可用本地存储的更多信息，请参阅 [Aurora MySQL 的临时存储限制临时存储限制](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage)。
## 优化 Aurora MySQL 数据库实例上的 temptable\$1max\$1mmap 参数
Aurora MySQL 中的 `temptable_max_mmap` 参数控制内存映射文件可以使用的最大本地磁盘空间量，超出此空间量之后，将溢出到磁盘上的 InnoDB 临时表（在写入器数据库实例上）或导致错误（在读取器数据库实例上）。正确设置此数据库实例参数有助于优化数据库实例的性能。
**先决条件**
1. 确保 Performance Schema 已启用。可以通过运行以下 SQL 命令进行验证：
```
SELECT @@performance_schema;
```
输出值为 `1` 表示已启用。
1. 确认临时表内存检测已启用。可以通过运行以下 SQL 命令进行验证：
```
SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%';
```
对于相关的临时表内存检测条目，`enabled` 列显示 `YES`。
**监控临时表使用情况**
建议您在设置 `temptable_max_mmap` 初始值时，一开始先设置为正在使用的数据库实例类的本地存储大小的 80%。这样可以确保临时表有足够的磁盘空间来高效运行，同时为实例上的其他磁盘使用留出空间。
要查找您的数据库实例类的本地存储大小，请参阅 [Aurora MySQL 的临时存储限制临时存储限制](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage)。
例如，如果您使用的是 db.r5.large 数据库实例类，则本地存储大小为 32 GiB。在本例中，最初应将 `temptable_max_mmap` 参数设置为 32 GiB 的 80%，即 25.6 GiB。
设置初始 `temptable_max_mmap` 值后，在 Aurora MySQL 实例上运行您的峰值工作负载。使用以下 SQL 查询监控当前的和较高的临时表磁盘使用率：
```
SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc
FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%';
```
此查询检索以下信息：
+ `event_name` – 临时表内存或磁盘使用事件的名称。
+ `current_count` – 分配的临时表内存或磁盘块的当前数量。
+ `current_alloc` – 为临时表分配的当前内存或磁盘量。
+ `current_avg_alloc` – 临时表内存或磁盘块的当前平均大小。
+ `high_count` – 分配的临时表内存或磁盘块的最大数量。
+ `high_alloc` – 为临时表分配的最大内存或磁盘量。
+ `high_avg_alloc` – 临时表内存或磁盘块的最大平均大小。
如果使用此设置时查询失败并出现 Table is full 错误，则表示您的工作负载需要更多磁盘空间才能完成临时表操作。在这种情况下，可以考虑增加数据库实例大小，以便有更多本地存储空间。
**设置最佳 `temptable_max_mmap` 值**
使用以下步骤监控 `temptable_max_mmap` 参数并为其设置适当的大小。
1. 查看上一个查询的输出，并确定临时表磁盘使用率峰值，如 `high_alloc` 列所示。
1. 根据临时表磁盘使用峰值，调整 Aurora MySQL 数据库实例的数据库参数组中的参数 `temptable_max_mmap`。
将值设置为比临时表磁盘使用量峰值略高一点，以适应未来的增长。
1. 将参数组更改应用于您的数据库实例。
1. 在工作负载高峰期再次监控临时表磁盘使用情况，以确保新 `temptable_max_mmap` 值合适。
1. 根据需要重复前面的步骤来微调 `temptable_max_mmap` 参数。
## 读取器数据库实例上用户创建的（显式）临时表
您可以在 `CREATE TABLE` 语句中使用 `TEMPORARY` 关键字创建显式临时表。Aurora 数据库集群中的写入器数据库实例支持显式临时表。您还可以在读取器数据库实例上使用显式临时表，但这些表无法强制使用 InnoDB 存储引擎。
为避免在 Aurora MySQL 读取器数据库实例上创建显式临时表时出现错误，请确保按以下任一或两种方式运行所有 `CREATE TEMPORARY TABLE` 语句：
+ 不要指定 `ENGINE=InnoDB` 子句。
+ 请勿将 SQL 模式设置为 `NO_ENGINE_SUBSTITUTION`。
## 临时表创建错误和缓解
您收到的错误会有所不同，具体取决于您使用的是简单 `CREATE TEMPORARY TABLE` 语句还是变体 `CREATE TEMPORARY TABLE AS SELECT`。以下示例显示不同类型的错误。
此临时表行为仅适用于只读实例。第一个示例证实了这是会话连接到的实例类型。
```
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
| 1 |
+--------------------+
```
对于简单的 `CREATE TEMPORARY TABLE` 语句，语句会在 `NO_ENGINE_SUBSTITUTION` SQL 模式开启时失败。当 `NO_ENGINE_SUBSTITUTION` 处于关闭状态（默认设置）时，将进行适当的引擎替换，并成功创建临时表。
```
mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';
mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';
mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB;
mysql> SHOW CREATE TABLE tt4\G
*************************** 1. row ***************************
Table: tt4
Create Table: CREATE TEMPORARY TABLE `tt4` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
```
对于 `CREATE TEMPORARY TABLE AS SELECT` 语句，语句会在 `NO_ENGINE_SUBSTITUTION` SQL 模式开启时失败。当 `NO_ENGINE_SUBSTITUTION` 处于关闭状态（默认设置）时，将进行适当的引擎替换，并成功创建临时表。
```
mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';
mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';
mysql> show create table tt3;
+-------+----------------------------------------------------------+
| Table | Create Table |
+-------+----------------------------------------------------------+
| tt3 | CREATE TEMPORARY TABLE `tt3` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
+-------+----------------------------------------------------------+
1 row in set (0.00 sec)
```
有关 Aurora MySQL 版本 3 中临时表的存储方面和性能影响的更多信息，请参阅博客文章[在 Amazon RDS for MySQL 和 Amazon Aurora MySQL 上使用 TempTable 存储引擎](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)。
# 比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3
使用以下内容了解在将 Aurora MySQL 版本 2 集群升级到版本 3 时需要注意的更改。
**Topics**
+ [原子数据定义语言（DDL）支持](#AuroraMySQL.Compare-v2-v3-atomic-ddl)
+ [Aurora MySQL 版本 2 和 3 之间的功能区别](#AuroraMySQL.Compare-v2-v3-features)
+ [实例类支持](#AuroraMySQL.mysql80-instance-classes)
+ [Aurora MySQL 版本 3 的参数更改](#AuroraMySQL.mysql80-parameter-changes)
+ [状态变量](#AuroraMySQL.mysql80-status-vars)
+ [Aurora MySQL 版本 3 的包容性语言更改](#AuroraMySQL.8.0-inclusive-language)
+ [AUTO\$1INCREMENT 值](#AuroraMySQL.mysql80-autoincrement)
+ [二进制日志复制](#AuroraMySQL.mysql80-binlog)
## 原子数据定义语言（DDL）支持
从 MySQL 5.7 到 8.0 的最大变化之一是引入了 [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)。在 MySQL 8.0 之前，MySQL 数据字典使用基于文件的方法，来将表定义 (.frm)、触发器 (.trg) 和函数等元数据与存储引擎的元数据（例如 InnoDB 的元数据）分开存储。这会有一些问题，包括以下这类情况：如果在 DDL 操作期间发生意外情况，导致基于文件的元数据和存储引擎元数据不同步，表就有变为“[orphaned](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html)”的风险。
为了解决这个问题，MySQL 8.0 引入了原子数据字典，它将所有元数据存储在架构 `mysql` 内的一组内部 InnoDB 表中。这种新架构提供了一种事务性、符合 [ACID](https://en.wikipedia.org/wiki/ACID) 的方法来管理数据库元数据，解决了基于文件的旧方法中的“原子 DDL”问题。有关原子数据字典的更多信息，请参阅《MySQL 参考手册》**中的 [Removal of file-based metadata storage](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) 和 [Atomic data definition statement support](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html)。
由于这种架构更改，从 Aurora MySQL 版本 2 升级到版本 3 时，必须考虑以下因素：
+ 在升级到版本 3 的过程中，必须将版本 2 中基于文件的元数据迁移到新的数据字典表中。这可能需要花一些时间，具体取决于要迁移的数据库对象数量。
+ 这些更改还引入了一些新的不兼容性，在从 MySQL 5.7 升级到 8.0 之前，可能需要解决这类问题。例如，8.0 有一些新的保留关键字，它们可能与现有的数据库对象名称冲突。
为了协助您在升级引擎之前确定这些不兼容性，在执行数据字典升级之前，Aurora MySQL 会运行一系列升级兼容性检查（预检查），来确定数据库字典中是否存在任何不兼容的对象。有关预检查的更多信息，请参阅 [Aurora MySQL 的主要版本升级预检查](AuroraMySQL.upgrade-prechecks.md)。
## Aurora MySQL 版本 2 和 3 之间的功能区别
在 Aurora MySQL for MySQL 5.7 中支持以下 Amazon Aurora MySQL 功能，但在 Aurora MySQL for MySQL 8.0 中不支持这些功能。
+ 您不能将 Aurora MySQL 版本 3 用于 Aurora Serverless v1 集群。Aurora MySQL 版本 3 可与 Aurora Serverless v2 一起使用。
+ 实验室模式不适用于 Aurora MySQL 版本 3。Aurora MySQL 版本 3 中没有任何实验室模式功能。即时 DDL 取代了以前在实验室模式下可用的快速线上 DDL 功能。有关示例，请参阅[即时 DDL（Aurora MySQL 版本 3）](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl)。
+ 查询缓存已从社区 MySQL 8.0 以及 Aurora MySQL 版本 3 中删除。
+ Aurora MySQL 版本 3 与社区 MySQL 即时哈希联接功能兼容。未使用 Aurora MySQL 版本 2 中特定于 Aurora 的哈希联接实现。有关在 Aurora 并行查询中使用哈希联接的信息，请参阅 [为并行查询集群开启哈希联接](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) 和 [Aurora MySQL 提示](AuroraMySQL.Reference.Hints.md)。有关哈希联接的一般用法信息，请参阅 *MySQL 参考手册*中的[哈希联接优化](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html)。
+ 在 Aurora MySQL 版本 2 中弃用的 `mysql.lambda_async` 存储过程将在版本 3 中删除。对于版本 3，请使用异步函数 `lambda_async`。
+ Aurora MySQL 版本 3 中的原定设置字符集是 `utf8mb4`。Aurora MySQL 版本 2 中的原定设置字符集是 `latin1`。有关此字符集的信息，请参阅 *MySQL 参考手册*中的 [utf8mb4 字符集（4 字节 UTF-8 Unicode 编码）](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)。
一些 Aurora MySQL 功能可用于 AWS 区域和数据库引擎版本的特定组合。有关详细信息，请参阅[Amazon Aurora 中受 AWS 区域 和 Aurora 数据库引擎支持的功能](Concepts.AuroraFeaturesRegionsDBEngines.grids.md)。
## 实例类支持
Aurora MySQL 版本 3 支持与 Aurora MySQL 版本 2 不同的一组实例类：
+ 对于较大的实例，您可以使用现代实例类，例如 `db.r5`、`db.r6g` 和 `db.x2g`。
+ 对于较大的实例，您可以使用现代实例类，例如 `db.t3` 和 `db.t4g`。
**注意**
建议仅将 T 数据库实例类用于开发和测试服务器，或其他非生产服务器。有关 T 实例类的更多详细信息，请参阅[使用 T 实例类进行开发和测试](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium)。
Aurora MySQL 版本 2 中的以下实例类不适用于 Aurora MySQL 版本 3：
+ `db.r4`
+ `db.r3`
+ `db.t3.small`
+ `db.t2`
检查您的管理脚本中是否有任何创建 Aurora MySQL 数据库实例的 CLI 语句。Aurora MySQL 版本 3 不可用的硬编码实例类名称。如有必要，请将实例类名称修改为 Aurora MySQL 版本 3 支持的名称。
**提示**
检查可用于 Aurora MySQL 版本和 AWS 区域特定组合的实例类，请使用 `describe-orderable-db-instance-options` AWS CLI 命令。
有关 Aurora 实例类的完整详细信息，请参阅 [Amazon Aurora数据库实例类](Concepts.DBInstanceClass.md)。
## Aurora MySQL 版本 3 的参数更改
Aurora MySQL 版本 3 包括新的集群级和实例级配置参数。Aurora MySQL 版本 3 还删除了 Aurora MySQL 版本 2 中存在的一些参数。由于包容性语言的倡议，一些参数名称发生了变化。为了向后兼容，您仍可以使用旧名称或使用新名称检索参数值。但是，您必须使用新名称在自定义参数组中指定参数值。
在 Aurora MySQL 版本 3 中，`lower_case_table_names` 参数的值在创建集群时永久设置。如果对此选项使用非原定设置值，请在升级之前设置 Aurora MySQL 版本 3 自定义参数组。然后，在创建集群或快照还原操作期间指定参数组。
**注意**
使用基于 Aurora MySQL 的 Aurora 全局数据库时，如果开启了 `lower_case_table_names` 参数，则无法执行从 Aurora MySQL 版本 2 到版本 3 的就地升级。改用快照还原方法。
在 Aurora MySQL 版本 3 中，`init_connect` 和 `read_only` 参数不适用于具有 `CONNECTION_ADMIN` 权限的用户。这包括 Aurora 主用户。有关更多信息，请参阅 [基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。
有关 Aurora MySQL 集群参数的完整列表，请参阅 [集群级别的参数](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster)。该表涵盖了 Aurora MySQL 版本 2 和 3 的所有参数。该表包括一些说明，显示了 Aurora MySQL 版本 3 中哪些参数是新增的，哪些参数已从 Aurora MySQL 版本 3 中删除。
有关 Aurora MySQL 实例参数的完整列表，请参阅 [实例级参数](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance)。该表涵盖了 Aurora MySQL 版本 2 和 3 的所有参数。该表包括一些说明，显示了 Aurora MySQL 版本 3 中哪些参数是新增的，哪些参数已从 Aurora MySQL 版本 3 中删除。它还包括显示哪些参数在早期版本中可修改，但不能在 Aurora MySQL 版本 3 中修改的说明。
有关已更改的参数名称的信息，请参阅 [Aurora MySQL 版本 3 的包容性语言更改](#AuroraMySQL.8.0-inclusive-language)。
## 状态变量
有关不适用于 Aurora MySQL 的状态变量的信息，请参阅 [不适用于 Aurora MySQL 的 MySQL 状态变量](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable)。
## Aurora MySQL 版本 3 的包容性语言更改
Aurora MySQL 版本 3 与 MySQL 社群版的 8.0.23 版本兼容。Aurora MySQL 版本 3 还包括 MySQL 8.0.26 中与包容性语言的关键字和系统架构相关的更改。例如，现在首选 `SHOW REPLICA STATUS` 命令，而不是 `SHOW SLAVE STATUS`。
以下 Amazon CloudWatch 指标在 Aurora MySQL 版本 3 中有新名称。
在 Aurora MySQL 版本 3 中，只有新的指标名称可用。升级到 Aurora MySQL 版本 3 时，请务必更新依赖指标名称的任何告警或其他自动化。
| 旧名称 | 新名称 |
| --- | --- |
| ForwardingMasterDMLLatency | ForwardingWriterDMLLatency |
| ForwardingMasterOpenSessions | ForwardingWriterOpenSessions |
| AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull |
| ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput |
以下状态变量在 Aurora MySQL 版本 3 中有新名称。
为了获得兼容性，您可以在初始的 Aurora MySQL 版本 3 中使用任何一个名称。未来版本将删除旧的状态变量名称。
| 要删除的名称 | 新名称或首选名称 |
| --- | --- |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout |
| Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions |
| Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit |
| Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout |
以下配置参数在 Aurora MySQL 版本 3 中有新名称。
为了获得兼容性，您可以在初始的 Aurora MySQL 版本 3 中使用任何一个名称以检查 `mysql` 客户端中的参数值。当修改自定义参数组中的值时，只能使用新名称。未来版本将删除旧的参数名称。
| 要删除的名称 | 新名称或首选名称 |
| --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct |
| master\$1verify\$1checksum | source\$1verify\$1checksum |
| sync\$1master\$1info | sync\$1source\$1info |
| init\$1slave | init\$1replica |
| rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout |
| log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements |
| slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet |
| slave\$1compressed\$1protocol | replica\$1compressed\$1protocol |
| slave\$1exec\$1mode | replica\$1exec\$1mode |
| slave\$1type\$1conversions | replica\$1type\$1conversions |
| slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum |
| slave\$1parallel\$1type | replica\$1parallel\$1type |
| slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order |
| log\$1slave\$1updates | log\$1replica\$1updates |
| slave\$1allow\$1batching | replica\$1allow\$1batching |
| slave\$1load\$1tmpdir | replica\$1load\$1tmpdir |
| slave\$1net\$1timeout | replica\$1net\$1timeout |
| sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter |
| slave\$1skip\$1errors | replica\$1skip\$1errors |
| slave\$1checkpoint\$1period | replica\$1checkpoint\$1period |
| slave\$1checkpoint\$1group | replica\$1checkpoint\$1group |
| slave\$1transaction\$1retries | replica\$1transaction\$1retries |
| slave\$1parallel\$1workers | replica\$1parallel\$1workers |
| slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max |
| pseudo\$1slave\$1mode | pseudo\$1replica\$1mode |
以下存储过程在 Aurora MySQL 版本 3 中有新名称。
为了获得兼容性，您可以在初始的 Aurora MySQL 版本 3 中使用任何一个名称。未来版本将删除旧的过程名称。
| 要删除的名称 | 新名称或首选名称 |
| --- | --- |
| mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position |
| mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source |
| mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position |
| mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source |
| mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log |
## AUTO\$1INCREMENT 值
在 Aurora MySQL 版本 3 中，Aurora 在重启每个数据库实例时保留每个表的 `AUTO_INCREMENT` 值。在 Aurora MySQL 版本 2 中，`AUTO_INCREMENT` 值在重启后不会保留。
当您通过从快照还原、执行时间点恢复和克隆集群来设置新集群时，不会保留 `AUTO_INCREMENT` 值。在这些情况下，`AUTO_INCREMENT` 值将根据创建快照时表中的最大列值初始化为该值。此行为与 RDS for MySQL 8.0 中的行为不同，其中 `AUTO_INCREMENT` 值在这些操作过程中将被保留。
## 二进制日志复制
在 MySQL 8.0 社群版中，预设情况下，二进制日志复制处于开启状态。预设情况下，在 Aurora MySQL 版本 3 中，二进制日志复制处于关闭状态。
**提示**
如果 Aurora 内置复制功能满足了您的高可用性要求，则可以关闭二进制日志复制。这样，您就可以避免二进制日志复制的性能开销。您还可以避免管理二进制日志复制所需的相关监控和故障排除过程。
Aurora 支持从兼容 MySQL 5.7 的源到 Aurora MySQL 版本 3 的二进制日志复制。源系统可以是 Aurora MySQL 数据库集群、RDS for MySQL 数据库实例或本地 MySQL 实例。
与社区 MySQL 一样，Aurora MySQL 支持从运行特定版本的源复制到运行相同主要版本或更高版本的目标。例如，不支持从兼容 MySQL 5.6 的系统复制到 Aurora MySQL 版本 3。不支持将 Aurora MySQL 版本 3 复制到兼容 MySQL 5.7 的系统或兼容 MySQL 5.6 的系统。有关使用二进制日志复制的详细信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
Aurora MySQL 版本 3 包括对社区 MySQL 8.0 中二进制日志复制的改进，例如筛选的复制。有关社区 MySQL 8.0 改进的详细信息，请参阅 *MySQL 参考手册*中的[服务器如何评估复制筛选规则](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)。
### 二进制日志复制的事务压缩
有关二进制日志压缩的使用信息，请参阅 MySQL 参考手册中的[二进制日志事务压缩](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html)。
以下限制适用于 Aurora MySQL 版本 3 中的二进制日志压缩：
+ 不会压缩其二进制日志数据大于允许的最大数据包大小的事务。无论是否开启 Aurora MySQL 二进制日志压缩设置，都是如此。此类事务在不被压缩的情况下被复制。
+ 如果您使用尚不支持 MySQL 8.0 的更改数据捕获 (CDC) 的连接器，则无法使用此功能。我们建议您使用二进制日志压缩彻底测试任何第三方连接器。此外，我们建议您在对 CDC 使用二进制日志复制的系统上开启二进制日志压缩之前先这样做。
# 比较 Aurora MySQL 版本 3 和 MySQL 8.0 社群版
您可以使用以下信息了解从不同的 MySQL 8.0 兼容系统转换为 Aurora MySQL 版本 3 时需要注意的更改。
一般来说，Aurora MySQL 版本 3 支持社区 MySQL 8.0.23 的功能集。MySQL 8.0 社群版的一些新功能不适用于 Aurora MySQL。其中一些功能与 Aurora 的某些方面不兼容，例如 Aurora 存储架构。不需要其他功能，因为 Amazon RDS 管理服务提供了同等的功能。社区 MySQL 8.0 中的以下功能不受支持或者在 Aurora MySQL 版本 3 中的工作方式有所不同。
有关所有 Aurora MySQL 版本 3 发布的发布说明，请参阅《Aurora MySQL 发布说明》中的 [Amazon Aurora MySQL 版本 3 的数据库引擎更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)**。
**Topics**
+ [MySQL 8.0 功能在 Aurora MySQL 版本 3 中不可用](#AuroraMySQL.Compare-80-v3-features)
+ [基于角色的权限模型](#AuroraMySQL.privilege-model)
+ [查找数据库服务器 ID](#AuroraMySQL.server-id)
+ [身份验证](#AuroraMySQL.mysql80-authentication)
## MySQL 8.0 功能在 Aurora MySQL 版本 3 中不可用
社区 MySQL 8.0 中的以下功能未提供或者在 Aurora MySQL 版本 3 中的工作方式有所不同。
+ Aurora MySQL 不支持资源组和相关的 SQL 语句。
+ Aurora MySQL 不支持用户定义的撤消表空间和关联的 SQL 语句，例如 `CREATE UNDO TABLESPACE`、`ALTER UNDO TABLESPACE ... SET INACTIVE` 和 `DROP UNDO TABLESPACE`。
+ 对于低于 3.06 的 Aurora MySQL 版本，Aurora MySQL 不支持撤消表空间截断。在 Aurora MySQL 3.06 及更高版本中，支持[自动撤消表空间截断](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace)。
+ 支持密码验证插件。
+ 您无法修改任何 MySQL 插件的设置，包括密码验证插件。
+ 不支持 X 插件。
+ 不支持多源复制。
## 基于角色的权限模型
使用 Aurora MySQL 版本 3，您无法直接修改 `mysql` 数据库中的表。特别是，您无法通过插入到 `mysql.user` 表来设置用户。相反，您可以使用 SQL 语句授予基于角色的权限。您也无法创建其他类型的对象，例如 `mysql` 数据库中的存储过程。您仍然可以查询 `mysql` 表。如果您使用二进制日志复制，则直接对源集群上的 `mysql` 表进行的更改不会复制到目标集群中。
在某些情况下，您的应用程序可能会使用快捷方式通过插入到 `mysql` 表来创建用户或其他对象。如果是这样，请更改应用程序代码以使用相应的语句，例如 `CREATE USER`。如果您的应用程序在 `mysql` 数据库中创建存储过程或其他对象，请改用其他数据库。
要在从外部 MySQL 数据库迁移期间导出数据库用户的元数据，您可以使用 MySQL Shell 命令而非 `mysqldump`。有关更多信息，请参阅 [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about)。
为了简化对许多用户或应用程序的权限管理，您可以使用 `CREATE ROLE` 语句来创建具有一组权限的角色。然后，您可以使用 `GRANT` 和 `SET ROLE` 语句以及 `current_role` 函数将角色分配给用户或应用程序、切换当前角色以及检查哪些角色有效。有关 MySQL 8.0 中基于角色的权限系统的更多信息，请参阅 MySQL 参考手册中的[使用角色](https://dev.mysql.com/doc/refman/8.0/en/roles.html)。
**重要**
我们强烈建议不要直接在应用程序中使用主用户。请遵守使用数据库用户的最佳实践，按照您的应用程序所需的最少权限创建用户。
**Topics**
+ [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role)
+ [二进制日志复制的权限检查用户](#AuroraMySQL.privilege-model.binlog)
+ [用于访问其它 AWS 服务的角色](#AuroraMySQL.privilege-model.other)
### rds\$1superuser\$1role
Aurora MySQL 版本 3 包括一个具有以下所有权限的特殊角色。该角色命名为 `rds_superuser_role`。每个集群的主管理用户已经授予了此角色。`rds_superuser_role` 角色包括所有数据库对象的以下权限：
+ `ALTER`
+ `APPLICATION_PASSWORD_ADMIN`
+ `ALTER ROUTINE`
+ `CONNECTION_ADMIN`
+ `CREATE`
+ `CREATE ROLE`
+ `CREATE ROUTINE`
+ `CREATE TEMPORARY TABLES`
+ `CREATE USER`
+ `CREATE VIEW`
+ `DELETE`
+ `DROP`
+ `DROP ROLE`
+ `EVENT`
+ `EXECUTE`
+ `FLUSH_OPTIMIZER_COSTS`（Aurora MySQL 版本 3.09 及更高版本）
+ `FLUSH_STATUS`（Aurora MySQL 版本 3.09 及更高版本）
+ `FLUSH_TABLES`（Aurora MySQL 版本 3.09 及更高版本）
+ `FLUSH_USER_RESOURCES`（Aurora MySQL 版本 3.09 及更高版本）
+ `INDEX`
+ `INSERT`
+ `LOCK TABLES`
+ `PROCESS`
+ `REFERENCES`
+ `RELOAD`
+ `REPLICATION CLIENT`
+ `REPLICATION SLAVE`
+ `ROLE_ADMIN`
+ `SET_USER_ID`
+ `SELECT`
+ `SHOW DATABASES`
+ `SHOW_ROUTINE`（Aurora MySQL 版本 3.04 及更高版本）
+ `SHOW VIEW`
+ `TRIGGER`
+ `UPDATE`
+ `XA_RECOVER_ADMIN`
角色定义还包括 `WITH GRANT OPTION`，以便管理用户可以将该角色授予其他用户。特别是，管理员必须授予以 Aurora MySQL 集群作为目标执行二进制日志复制所需的任何权限。
**提示**
要查看权限的完整详细信息，请输入以下语句。
```
SHOW GRANTS FOR rds_superuser_role@'%';
SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';
```
### 二进制日志复制的权限检查用户
Aurora MySQL 版本 3 包括二进制日志（binlog）复制的权限检查用户，即 `rdsrepladmin_priv_checks_user`。除 `rds_superuser_role` 的权限之外，此用户还拥有 `replication_applier` 权限。
当您通过调用 `mysql.rds_start_replication` 存储过程来开启二进制日志复制时，即会创建 `rdsrepladmin_priv_checks_user`。
`rdsrepladmin_priv_checks_user@localhost` 用户是保留用户。请勿修改此用户。
### 用于访问其它 AWS 服务的角色
Aurora MySQL 版本 3 包括可用于访问其它 AWS 服务的角色。可以将其中许多角色设置为授予权限的替代。例如，您可以指定 `GRANT AWS_LAMBDA_ACCESS TO user` 而不是 `GRANT INVOKE LAMBDA ON *.* TO user`。对于访问其他 AWS 服务的程序，请参阅 [将 Amazon Aurora MySQL 与其他AWS服务集成](AuroraMySQL.Integrating.md)。Aurora MySQL 版本 3 包括以下与访问其他 AWS 服务相关的角色：
+ `AWS_LAMBDA_ACCESS` – `INVOKE LAMBDA` 权限的替代。有关使用信息，请参阅[从 Amazon Aurora MySQL 数据库集群中调用 Lambda 函数](AuroraMySQL.Integrating.Lambda.md)。
+ `AWS_LOAD_S3_ACCESS` – `LOAD FROM S3` 权限的替代。有关使用信息，请参阅[将数据从 Amazon S3 存储桶中的文本文件加载到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Integrating.LoadFromS3.md)。
+ `AWS_SELECT_S3_ACCESS` – `SELECT INTO S3` 权限的替代。有关使用信息，请参阅[将数据从 Amazon Aurora MySQL 数据库集群保存到 Amazon S3 存储桶中的文本文件](AuroraMySQL.Integrating.SaveIntoS3.md)。
+ `AWS_COMPREHEND_ACCESS` – `INVOKE COMPREHEND` 权限的替代。有关使用信息，请参阅[授予数据库用户访问 Aurora 机器学习的权限](mysql-ml.md#aurora-ml-sql-privileges)。
+ `AWS_SAGEMAKER_ACCESS` – `INVOKE SAGEMAKER` 权限的替代。有关使用信息，请参阅[授予数据库用户访问 Aurora 机器学习的权限](mysql-ml.md#aurora-ml-sql-privileges)。
+ `AWS_BEDROCK_ACCESS` – Amazon Bedrock 没有类似的 `INVOKE` 权限。有关使用信息，请参阅[授予数据库用户访问 Aurora 机器学习的权限](mysql-ml.md#aurora-ml-sql-privileges)。
当您使用 Aurora MySQL 版本 3 中的角色授予访问权限时，还可以通过使用 `SET ROLE role_name` 或 `SET ROLE ALL` 语句来激活角色。下面的示例演示如何操作。将适当的角色名称替换为 `AWS_SELECT_S3_ACCESS`。
```
# Grant role to user.
mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address'
# Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated.
# Only the rds_superuser_role is currently in effect.
mysql> SELECT CURRENT_ROLE();
+--------------------------+
| CURRENT_ROLE() |
+--------------------------+
| `rds_superuser_role`@`%` |
+--------------------------+
1 row in set (0.00 sec)
# Activate all roles associated with this user using SET ROLE.
# You can activate specific roles or all roles.
# In this case, the user only has 2 roles, so we specify ALL.
mysql> SET ROLE ALL;
Query OK, 0 rows affected (0.00 sec)
# Verify role is now active
mysql> SELECT CURRENT_ROLE();
+-----------------------------------------------------+
| CURRENT_ROLE() |
+-----------------------------------------------------+
| `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` |
+-----------------------------------------------------+
```
## 查找数据库服务器 ID
数据库服务器 ID（`server_id`）是二进制日志（binlog）复制所必需的。在 Aurora MySQL 中查找服务器 ID 的方式与在 Community MySQL 中查找不同。
在 Community MySQL 中，服务器 ID 是一个数字，您可以在登录服务器时使用以下语法获得：
```
mysql> select @@server_id;
+-------------+
| @@server_id |
+-------------+
| 2 |
+-------------+
1 row in set (0.00 sec)
```
在 Aurora MySQL 中，服务器 ID 是数据库实例 ID，您可以在登录数据库实例时使用以下语法获得：
```
mysql> select @@aurora_server_id;
+------------------------+
| @@aurora_server_id |
+------------------------+
| mydbcluster-instance-2 |
+------------------------+
1 row in set (0.00 sec)
```
有关二进制日志复制的更多信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
## 身份验证
在社区 MySQL 8.0 中，默认的身份验证插件是 `caching_sha2_password`。Aurora MySQL 版本 3 仍然使用 `mysql_native_password` 插件。您将无法更改 `default_authentication_plugin` 设置。但是，您可以创建新用户和更改当前用户，并且这些用户各自的密码使用新的身份验证插件。以下为示例。
```
mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword';
Query OK, 0 rows affected (0.74 sec)
```
# 升级到 Aurora MySQL 版本 3
有关将数据库从 Aurora MySQL 版本 2 升级到版本 3 的信息，请参阅[升级 Amazon Aurora MySQL 数据库集群的主要版本](AuroraMySQL.Updates.MajorVersionUpgrade.md)。