从AWS Aurora MySQL迁移至Azure SQL：基于DTU模型的环境选型

目前没有直接的一对一映射计算器能精准将AWS Aurora MySQL实例转换为Azure SQL的DTU级别——因为两者的资源模型、架构逻辑差异很大：Aurora实例是基于硬件规格（vCPU、内存）定义，而DTU是Azure整合CPU、内存、IO、带宽的综合性能指标。

你可以按照以下步骤来匹配合适的Azure SQL DTU规格（以db.r5.12xlarge为例）：

• 第一步：收集Aurora实例的实际负载数据
  不要只看实例的标称规格，重点抓生产环境的真实负载指标：

  • CPU使用率（峰值、平均）
  • 内存消耗情况
  • 读写IOPS、吞吐量
  • 活跃数据库连接数
    这些数据可以从AWS CloudWatch的历史监控报表中提取，取近1-2周的高峰时段数据更有参考性。

• 第二步：对照Azure SQL DTU层级的资源限制
  打开Azure SQL单数据库的DTU定价页面，查看各层级（Basic/Standard/Premium）的详细参数：

  • Premium层级是为高负载场景设计的，db.r5.12xlarge（48vCPU、192GB内存）属于大规格实例，对应Premium里的高DTU档位。比如P6（4000 DTU）对应24vCPU、140GB内存，P7（8000 DTU）对应32vCPU、280GB内存，这两个档位的资源量级和你的Aurora实例最接近。
  • 重点对比你收集的负载数据和DTU档位的资源上限，比如如果你的Aurora峰值IOPS很高，就需要优先看DTU档位的IO限制。

• 第三步：测试验证调整
  直接按标称规格匹配可能会有误差，建议：

  1. 先创建一个目标DTU档位的Azure SQL实例
  2. 用压测工具（如HammerDB、JMeter）模拟生产级别的负载
  3. 监控Azure SQL的CPU、IO、连接数等指标，根据实际性能表现调整DTU级别——如果负载压力下指标余量充足，可以降档；如果资源瓶颈明显，就需要升级DTU。

内容的提问来源于stack exchange，提问作者Viktor