Aurora MySQL 3.14正式可用:新增后量子TLS混合密钥交换(需客户端也支持),DELETE增加RETURNING使其成为保留字,行大小行为保持旧版而非社区8.0.46

Published · AI Daily — AI-assisted deep research, methodology & disclosure

2026年11月2日,AWS宣布Aurora MySQL 3.14(兼容MySQL 8.0.46)正式可用,主打后量子TLS(PQ-TLS)密钥交换。发布说明显示,它在TLS 1.3上新增X25519MLKEM768和SecP256r1MLKEM768混合组,只有客户端也支持时才协商,否则仍用传统组,可用Aurora_ssl_named_group状态变量核对。另有从3.08起更快的小版本升级、单表DELETE的RETURNING(RETURNING成为保留字,同名标识符须加反引号)、FTSCacheMemoryUsed指标,并保留ERROR 1118之前的行大小行为,与社区8.0.46不同。审计日志现在记录调用客户端而非定义者。说明页日期为10月26日,且无升级速度或TLS开销数据。

2026年11月2日,AWS宣布Amazon Aurora MySQL兼容版3(MySQL 8.0系列)现在以Aurora MySQL 3.14的形式支持MySQL 8.0.46。公告说该版本带有社区MySQL修复和Aurora专有改进,主打新增是对后量子TLS(PQ-TLS)密钥交换的支持。所有提供Aurora MySQL的AWS区域都可用。有一个日期需要留意:Aurora发布说明把3.14.0列在2026-10-26的日期下,所以该引擎的文档比“从今天起”的公告早了大约一周。

公告很短,发布说明解释了后量子功能做了什么。Aurora MySQL为TLS 1.3连接,在传统椭圆曲线组之外增加了两个混合密钥交换组:X25519MLKEM768和SecP256r1MLKEM768。支持后量子密钥交换的客户端会自动协商出抗量子的共享密钥,不支持的客户端继续使用传统组。所以这并不是在服务器上拨一个开关就生效:只有客户端库也支持这些组并使用TLS 1.3时才会发生。要查看会话协商了什么,可运行SHOW STATUS LIKE 'Aurora_ssl_named_group'。

发布说明里列出的其他变化,对运维人员可能更重要。从3.08或更高版本升级到3.14的小版本升级现在完成得更快,写入实例更早恢复服务,无需配置更改或选择加入。单表DELETE语句增加了RETURNING子句,可以在不另写SELECT的情况下返回被删除行的值。由于RETURNING现在是保留字,任何名为returning的标识符都必须用反引号括起来,未加引号的在升级后会解析失败。新的CloudWatch指标FTSCacheMemoryUsed显示实例上所有表的InnoDB全文搜索缓存所用内存。

有一个兼容性选择值得细读。社区MySQL 8.0.46改变了对某些类型的多列表的处理,所以创建这类表可能以ERROR 1118“Row size too large”失败,尽管同样的语句在更早的8.0版本上能成功。发布说明称,Aurora MySQL 3.14.0保留了旧行为,所以这些语句仍和3.13.0及更早版本一样工作。这意味着Aurora 3.14在这一点上与社区8.0.46不同,如果你在两者之间测试或迁移,这一点很重要。

发布说明还列出了安全修复。Advanced Audit日志以前在SQL SECURITY DEFINER例程内执行的语句上,记录的是定义者的用户和主机,而不是调用客户端,现在改为记录调用的客户端。预处理语句不再产生重复的审计条目。另有一项修复针对使用写入转发的会话中,SET ROLE NONE没有清除先前角色的权限,可能允许本应被拒绝的操作。该版本还列出了两个高危CVE和一份较长的中危CVE修复。把审计日志用于合规解析的团队,应预期升级后用户和主机的取值会变化。

关于推出,AWS说可以在维护窗口内通过自动小版本升级来升级,AWS Organizations的升级推出策略可以在多个集群上分阶段升级。升级可以原地进行,也可以通过快照恢复。对团队来说,实用清单很短:若目标是PQ-TLS,检查客户端库是否协商混合组;在代码中搜索未加引号的returning标识符;复核审计日志的使用方;先在较低环境测试。公告和发布说明没有给出更快升级的速度数字,也没有给出任何TLS开销数据。

简单概括:Aurora MySQL 3.14兼容MySQL 8.0.46,新增后量子TLS混合密钥交换、更快的小版本升级、单表DELETE的RETURNING和FTSCacheMemoryUsed指标。升级前要核对五点。第一,混合密钥交换组只有在客户端库也支持并使用TLS 1.3时才会被协商,否则仍用传统组。第二,RETURNING成为保留字,名为returning的标识符必须加反引号。第三,审计日志在定义者例程中改为记录调用客户端,依赖旧值的解析需要复核。第四,Aurora保留8.0.46之前的行大小行为,与社区8.0.46不同。第五,发布说明的日期是10月26日,比11月2日的公告早约一周。公告和说明都没有给出升级速度或TLS开销的数字。

补充一点:发布说明还列出了安全修复。Advanced Audit日志此前在SQL SECURITY DEFINER例程内记录的是定义者而不是调用客户端;预处理语句会产生重复的审计条目;使用写入转发的会话中,SET ROLE NONE没有清除先前角色的权限,可能允许本应被拒绝的操作。此外还有两个高危CVE和一份较长的中危CVE修复。推出方面,AWS说可以通过自动小版本升级在维护窗口内升级,并可用AWS Organizations的升级推出策略在多个集群上分阶段进行;升级可以原地进行,也可以通过快照恢复;从3.08或更高版本升级到3.14的小版本升级现在完成得更快,无需配置更改。

Sources

FAQ

升级到Aurora MySQL 3.14后,连接就自动抗量子了吗?

不一定。发布说明在TLS 1.3上新增X25519MLKEM768和SecP256r1MLKEM768混合组,但只有客户端也支持后量子密钥交换才协商,否则仍用传统组。可用Aurora_ssl_named_group状态变量查看实际结果。

升级前代码里最容易踩到的兼容问题是什么?

RETURNING现在是保留字,因为单表DELETE新增了RETURNING子句。名为returning的标识符必须加反引号,否则升级后解析失败。审计日志在定义者例程中改为记录调用客户端,依赖旧用户或主机值的解析要复核。

Aurora 3.14的行大小行为和社区MySQL 8.0.46一样吗?

不一样。社区8.0.46对某些多列表报ERROR 1118“Row size too large”,而发布说明称Aurora MySQL 3.14.0保留8.0.46之前的行为,这些语句仍像3.13.0及更早版本一样成功。在两者间测试或迁移时要留意。