基于 DTU 的购买模型概述
适用于：
Azure SQL 数据库
本文介绍 Azure SQL 数据库的基于 DTU 的购买模型。
有关详细信息，请查看基于 vCore 的购买模型和比较购买模型。
数据库事务单位 (DTU)
数据库事务单位 (DTU) 表示 CPU、内存、读取和写入的混合度量。 基于 DTU 的购买模型中的服务层级根据一系列具有固定随附存储量、固定备份保留期和固定价格的计算大小进行区分。 基于 DTU 的购买模型中的所有服务层级都提供了以最短停机时间更改计算大小的灵活性；但是，在切换期间，与数据库的连接会短时间丢失，可以使用重试逻辑来缓解这种情况。 单一数据库和弹性池根据服务层级和计算大小按小时计费。
对于服务层级内特定计算大小的单一数据库，Azure SQL 数据库保证该数据库（独立于任何其他数据库）可获得一定级别的资源。 这可以保证提供可预测的性能级别。 为数据库分配的资源量是以若干 DTU 计算的，是计算资源、存储资源和 I/O 资源的捆绑度量值。
这些资源之间的比率最初由联机事务处理 (OLTP) 基准工作负荷决定，后者旨在作为典型的真实 OLTP 工作负荷。 工作负荷超过任何以上资源量时，吞吐量将受到限制，从而导致性能下降和超时。
对于单一数据库，工作负荷使用的资源不会影响 Azure 云中其他数据库的可用资源。 同样，其他工作负荷使用的资源也不会影响你的数据库可用的资源。
DTU 最好地解释了在不同计算大小和服务层级为数据库分配的相对资源量。 例如：
- 提高数据库的计算大小可使 DTU 加倍，这等同于使该数据库可用的资源集增加一倍。
- 具有 1750 个 DTU 的高级服务层级 P11 数据库提供的 DTU 计算能力是具有 5 个 DTU 的基本服务层级数据库的 350 倍。
若要更深入地了解工作负荷的资源 (DTU) 消耗，请使用查询性能见解：
- 按 CPU/持续时间/执行计数确定热门查询，可以对这些查询进行调整来提高性能。 例如，I/O 密集型查询可能会受益于内存中优化技术，以便通过特定的服务层级和计算大小更好地利用可用内存。
- 深入了解查询详情，查看其文本和资源用量历史记录。
- 查看性能优化建议，这些建议显示了 SQL 数据库顾问执行的操作。
弹性数据库事务单位 (eDTU)
可将这些数据库放入弹性池，而不必提供一组专用资源 (DTU)，因为有时可能并不需要这些资源。 弹性池中的数据库使用数据库引擎的单个实例，并共享同一资源池。
弹性池中的共享资源用弹性数据库事务单位 (eDTU) 度量。 弹性池是一种简单的低成本高效益的解决方案，用于管理使用模式变化很大且不可预测的多个数据库的性能目标。 弹性池可保证不出现一个数据库使用池中所有资源的情况，同时确保池中的每个数据库始终可以使用最少量的必需资源。
为池提供的 eDTU 的数量和价格是固定的。 在弹性池中，单个数据库可在配置的边界内自动缩放。 负载较重的数据库消耗较多的 eDTU 来满足需求。 负载较轻的数据库消耗较少的 eDTU。 无负载的数据库不消耗任何 eDTU。 由于资源是为整个池预配的，而不是为每个数据库预配的，因此弹性池可以简化管理任务，使池的预算可预测。
可在尽量缩短数据库停机时间的情况下向现有池添加更多的 eDTU。 同样，可以随时从现有池中删除不再需要的额外 eDTU。 还可以随时在池中添加或删除数据库。 若要为其他数据库预留 eDTU，可以限制重负载数据库的可用 eDTU 数目。 如果数据库的资源利用率一贯较高，影响池中的其他数据库，请将其移出池，并使用所需的可预测资源量将它配置为单一数据库。
受益于资源弹性池的工作负荷
池很适合用于低平均资源利用率和相对不频繁的使用高峰的数据库。 有关详细信息，请参阅何时应当考虑使用 SQL 数据库弹性池？。
确定工作负荷所需的 DTU 数
若要将现有的本地或 SQL Server 虚拟机工作负荷迁移到 SQL 数据库，请参阅 SKU 建议来估算所需的 DTU 数目。 对于现有的 SQL 数据库工作负荷，可以使用查询性能见解来了解数据库资源使用量 (DTU)，更深入地了解如何优化工作负荷。 使用 sys.dm_db_resource_stats 动态管理视图 (DMV) 可以查看过去一小时的资源消耗。 sys.resource_stats 目录视图显示过去 14 天的资源消耗，不过，五分钟平均值的准确性较低。
确定 DTU 利用率
若要相对于数据库或弹性池的 DTU/eDTU 限制确定 DTU/eDTU 利用率平均百分比，请使用以下公式：
avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)
可从 sys.dm_db_resource_stats、sys.resource_stats 和 sys.elastic_pool_resource_stats DMV 获取此公式的输入值。 换言之，若要相对于数据库或弹性池的 DTU/eDTU 限制确定 DTU/eDTU 利用率百分比，请从 avg_cpu_percent、avg_data_io_percent 和 avg_log_write_percent 中拾取给定时间点的最大百分比值。
注意
数据库的 DTU 限制由 CPU、读取次数、写入次数和数据库的可用内存决定。 但是，由于 SQL 数据库引擎通常会使用所有可用内存来使其数据缓存提高性能，不管当前数据库负载如何，avg_memory_usage_percent 值通常都接近 100%。 因此，尽管内存确实会间接影响 DTU 限制，但 DTU 利用率公式中并不使用内存值。
比较服务层级
选择服务层级首要考虑的是业务连续性、存储和性能需求。
| 基本 | 标准 | 高级 | |
|---|---|---|---|
| 目标工作负荷 | 开发和生产 | 开发和生产 | 开发和生产 |
| 运行时间 SLA | 99.99% | 99.99% | 99.99% |
| 备份 | 选择异地冗余、区域冗余或本地冗余备份存储，1-7 天保留期（默认为 7 天） 长期保留期最长为 10 年 |
选择异地冗余、区域冗余或本地冗余备份存储，1-35 天保留期（默认为 7 天） 长期保留期最长为 10 年 |
选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天（默认值为 7 天）的保留期，最长的长期保留期为 10 年 |
| CPU | 低 | 低、中、高 | 中、高 |
| IOPS（近似）* | 每个 DTU 1-4 IOPS | 每个 DTU 1-4 IOPS | >每个 DTU 25 IOPS |
| IO 延迟（近似） | 5 毫秒（读取），10 毫秒（写入） | 5 毫秒（读取），10 毫秒（写入） | 2 毫秒（读取/写入） |
| 列存储索引 | 空值 | 标准 S3 及更高层级 | 支持 |
| 内存中 OLTP | 空值 | 空值 | 支持 |
* 针对数据文件的所有读取和写入 IOPS，包括后台 IO（检查点和惰性编写器）。
重要
基本、S0、S1 和 S2 服务目标提供的 vCore (CPU) 不到一个。 对于 CPU 密集型工作负载，建议使用 S3 或更高的服务目标。
在基本、S0 和 S1 服务目标中，数据库文件存储在 Azure 标准存储中，该存储使用基于硬盘驱动器 (HDD) 的存储介质。 这些服务目标最适合用于对性能变化不太敏感的开发、测试和其他不频繁访问的工作负载。
提示
若要查看数据库或弹性池的实际资源调控限制，请查询 sys.dm_user_db_resource_governance 视图。 对于单一数据库，返回一行。 对于弹性池中的数据库，则为池中的每个数据库都返回一行。
资源限制
单一数据库和共用数据库的资源限制不同。
单一数据库存储限制
在 Azure SQL 数据库中，单一数据库的计算大小以数据库事务单位 (DTU) 表示，弹性池则以弹性数据库事务单位 (eDTU) 表示。 有关详细信息，请查看单一数据库的资源限制。
| 基本 | 标准 | 高级 | |
|---|---|---|---|
| 最大存储大小 | 2 GB | 1 TB | 4 TB |
| 最大 DTU | 5 | 3000 | 4000 |
重要
在某些情况下，可能需要收缩数据库来回收未使用的空间。 有关详细信息，请参阅管理 Azure SQL 数据库中的文件空间。
弹性池限制
有关详细信息，请查看共用数据库的资源限制。
| 基本 | 标准 | 高级 | |
|---|---|---|---|
| 每个数据库的最大存储大小 | 2 GB | 1 TB | 1 TB |
| 每个池的最大存储大小 | 156 GB | 4 TB | 4 TB |
| 每个数据库的最大 eDTU 数 | 5 | 3000 | 4000 |
| 每个池的最大 eDTU 数 | 1600 | 3000 | 4000 |
| 每个池的数据库数目上限 | 500 | 500 | 100 |
重要
在某些情况下，可能需要收缩数据库来回收未使用的空间。 有关详细信息，请参阅管理 Azure SQL 数据库中的文件空间。
DTU 基准
使用模拟真实数据库工作负载的基准校准与每个 DTU 度量值相关的物理特性（CPU、内存、IO）。
了解架构、使用的事务类型、工作负载组合、用户和节奏、缩放规则以及与 DTU 基准相关的指标。
比较基于 DTU 和 vCore 的购买模型
虽然基于 DTU 的购买模型以计算、存储和 I/O 资源的捆绑度量值为基础，但相比之下，Azure SQL 数据库的 vCore 购买模型可让你独立选择和缩放计算及存储资源。
利用基于 vCore 的购买模型，还可为 SQL Server 使用 Azure 混合权益以节省成本，并为 Azure SQL 数据库提供无服务器和超大规模选项，而这些选项在基于 DTU 的购买模型中不可用。
在比较 Azure SQL 数据库的基于 vCore 的和基于 DTU 的购买模型中了解详细信息。
后续步骤
参阅以下文章，详细了解如何购买模型以及相关概念：
- 有关适用于单一数据库的特定计算大小和存储大小选项的详细信息，请参阅适用于单一数据库的 SQL 数据库基于 DTU 的资源限制。
- 有关适用于弹性池的特定计算大小和存储大小选项的详细信息，请参阅 SQL 数据库基于 DTU 的资源限制。
- 有关与基于 DTU 的购买模型相关的基准的信息，请参阅 DTU 基准。
- 比较 Azure SQL 数据库的基于 vCore 的和基于 DTU 的购买模型。