概述：从硬件适配到数据库性能交付

既要扛住高并发交易，又要运行分析负载，还要控制资源与运维成本，是数据库用户面临的现实问题。

阿里云 RDS MySQL 在 AMD EPYC 平台上完成了硬件适配与数据库内核优化。通过适配 CPU 拓扑、NUMA、本地内存访问和云存储 I/O 路径，RDS MySQL 将 AMD 平台的高核心密度、内存带宽和 I/O 扩展能力转化为稳定的数据库性能。同时，RDS MySQL 持续优化 InnoDB 事务链路，引入 DuckDB 列式分析能力，增强 TP 与 AP 性能。

硬件适配：把平台能力转化为数据库服务能力

数据库性能对硬件特征高度敏感：核心规模与拓扑决定并发扩展能力，NUMA 影响内存访问效率，存储与 I/O 路径关系到读写吞吐和稳定性。因此，RDS MySQL 关注的是整机拓扑、云存储与实例规格的整体匹配。

2.1 硬件能力基础

从数据库负载视角来看，AMD EPYC 平台主要在算力、内存与 I/O、能效和安全隔离四个方面，为云数据库提供底层支撑。

首先是算力密度。高核心数配合 SMT 多线程和大容量缓存，为高并发处理和大规格实例提供算力基础。

其次是内存与 I/O 能力。多通道内存为 Buffer Pool 访问以及排序、聚合等操作提供内存带宽；高速 PCIe 连接提供 I/O 扩展能力，支持 CXL 的平台还可扩展内存和设备互联能力。

第三是能效表现。更优的性能与能效比有助于提高实例部署密度，降低总体拥有成本。

最后是安全与隔离能力。AMD Infinity Guard 安全体系涵盖 SME、SEV 和 SEV-SNP 等能力，为内存保护、虚拟机加密和多租户隔离提供硬件基础。

2.2 面向数据库负载的平台适配

AMD 平台适配并非简单切换 CPU，而是围绕实例运行方式重新匹配计算、内存、存储和网络资源。针对高核心密度和 NUMA 拓扑，RDS MySQL 按实例规格约束 CPU 范围与内存分配，使线程尽量使用本地 NUMA 资源，减少跨节点访问和后台线程干扰。

除 CPU 与内存外，存储和网络也需要按照数据库的实际 I/O 路径进行验证。Redo 日志和 Binlog 对写入时延与 fsync 稳定性更敏感；数据文件写入和刷脏操作更依赖持续吞吐；读请求和临时文件则容易受到云盘 IOPS、带宽上限以及抖动影响。因此，RDS MySQL 将日志路径、数据文件路径、云盘 IOPS、云盘带宽、网络带宽与实例规格进行统一评估，确保 CPU 算力提升后，I/O 供给不会成为新的瓶颈。

图 1：AMD EPYC 平台能力与 RDS MySQL 面向数据库负载的适配。

软件优化：面向关键路径的数据库内核演进

硬件提供了性能基础，但数据库性能并不只由硬件规格决定。对于云数据库而言，事务处理、数据访问、存储交互和分析执行等核心链路，决定了底层资源能否被高效组织和利用。

围绕这一目标，RDS MySQL 针对 TP 与 AP 两类负载形成差异化优化方向：在线事务侧重点优化恢复、云存储 I/O、在线变更、提交与复制；在线分析侧则融合 DuckDB，将列式存储、向量化执行和自适应压缩等能力引入 MySQL。

3.1 OLTP：优化在线数据库核心链路

对于核心业务系统来说，数据库性能不仅体现在峰值 QPS 上，也体现在故障后的恢复时间、业务高峰期的提交稳定性、在线变更对业务的影响，以及主备复制链路能否持续跟上写入压力。

在恢复与存储路径方面，RDS MySQL 通过精简启动扫描范围、优化 Buffer Pool 初始化，并将 Redo 恢复组织为流水线并行处理；同时针对云存储的远程链路和抖动特征，在具备全链路原子写能力的路径上减少 Doublewrite 带来的写放大，并通过 Buffer Pool Extension 缓冲云盘抖动。

在在线变更、提交与复制链路方面，RDS MySQL 持续扩展 Instant DDL 的适用范围，优化 Inplace DDL 的内存、排序和刷脏路径；同时以 Binlog in Redo 优化提交路径，并结合大事务优化和实时复制能力，降低高并发写入与复制延迟对在线业务的影响。

图 2：RDS MySQL 围绕恢复、存储、在线变更、提交与复制四条核心链路持续优化。

3.2 HTAP：以 DuckDB 扩展 MySQL 的列式分析能力

随着业务数据持续增长，越来越多用户希望在保留 MySQL 使用习惯的同时，直接对历史数据、明细数据和运营数据进行分析。传统方案通常需要将数据同步到外部分析系统，不仅链路更长、组件更多，也会带来额外的运维成本和一致性挑战。RDS MySQL DuckDB 的思路，是在 MySQL 产品体系内补齐列式分析能力，让用户无需额外维护一套独立分析数据库。

查询请求仍由 MySQL Server 层接入，再交由 DuckDB 执行分析路径。RDS MySQL 对语法、函数和字符集等能力进行增强，使用户获得的仍然是 MySQL 形态下的分析能力。DuckDB 以列为单位组织数据，并按列类型和数据分布选择编码与压缩策略，从而减少无关列扫描。

在写入与同步方面，RDS MySQL DuckDB 重新组织导入和增量写入模型，并改造 Binlog 回放、事务提交和异常恢复过程。产品上已形成分析只读实例和分析主实例两类形态，分别用于隔离分析负载，以及支持写入、汇聚和高可用。

图 3：应用继续使用 MySQL 入口，InnoDB 与 DuckDB 分别承接事务与分析负载。

对比验证：AMD 平台上的 RDS MySQL 性能表现

为了观察平台差异，我们选取在线处理与在线分析两类典型负载进行验证。以下结果反映相同实例规格、数据集和负载配置下的平台差异，实际收益还会受到数据模型、并发度、SQL 形态和存储配置等因素影响。

4.1 在线事务处理场景

在在线处理场景中，我们选取 sysbench read-write 读写混合负载，对不同实例规格下的平台表现进行对比。结果显示，在 8C、16C、32C 等常见规格上，AMD 平台相比同规格对照平台峰值吞吐分别提升 46%、57% 和 32%。对于 RDS MySQL 这类长期运行的在线数据库而言，更高的峰值吞吐意味着在相同实例规格下，数据库可以承接更高并发，并在业务高峰和弹性扩容时保留更充裕的容量余量。

4.2 在线分析场景

在分析场景中，我们进一步对 RDS MySQL DuckDB 进行了平台对比测试。在 32C128G 规格下，基于 TPC-H SF100 数据集对 Q1-Q22 查询进行逐条对比，覆盖列式扫描、过滤、聚合和 Join 等典型分析路径。结果显示，AMD 平台在 22 条查询上性能提升 1.25 倍～ 1.82 倍不等；按累计耗时计算，性能约为同规格对照平台的 1.5 倍。

测试结果说明，AMD 平台带来的收益并不局限于事务处理，同样可以覆盖 DuckDB 所承接的列式分析负载。在归档分析、运营分析和历史数据查询等场景下，这意味着更短的查询耗时和更高的分析效率。

图 4：AMD 平台上的 RDS MySQL 在线处理与分析对比结果。

从性能提升到业务价值

从用户视角看，RDS MySQL on AMD EPYC 的价值并不止于性能提升本身，更在于让同一套数据库产品体系承接更多原本需要拆分到多套系统中的任务：核心交易和高并发访问仍由 RDS MySQL 承载，历史明细分析、运营报表和归档查询则可以借助 DuckDB 的列式分析能力完成。

对于云数据库来说，硬件规格决定性能上限，产品能力决定这些资源能否转化为用户可感知的吞吐、时延和稳定性。AMD EPYC 提供算力基础，RDS MySQL 则通过持续演进的事务与分析能力，将这些资源进一步转化为更稳定、更高效的数据库服务。