基于 DTU 的购买模型中的服务层Service tiers in the DTU-based purchase model

适用于: Azure SQL 数据库

基于 DTU 的购买模型中的服务层级根据一系列具有固定随附存储量、固定备份保留期和固定价格的计算大小进行区分。Service tiers in the DTU-based purchase model are differentiated by a range of compute sizes with a fixed amount of included storage, fixed retention period for backups, and fixed price. 基于 DTU 的购买模型中的所有服务层级都提供了以最短停机时间更改计算大小的灵活性;但是,在切换期间,与数据库的连接会短时间丢失,可以使用重试逻辑来缓解这种情况。All service tiers in the DTU-based purchase model provide flexibility of changing compute sizes with minimal downtime; however, there is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic. 单一数据库和弹性池根据服务层级和计算大小按小时计费。Single databases and elastic pools are billed hourly based on service tier and compute size.


Azure SQL 托管实例不支持基于 DTU 的购买模型。Azure SQL Managed Instance does not support a DTU-based purchasing model.


有关基于 vCore 的服务层级的信息,请参阅基于 vCore 的服务层级For information about vCore-based service tiers, see vCore-based service tiers. 要了解如何区分基于 DTU 的服务层级和基于 vCore 的服务层级,请参阅购买模型For information about differentiating DTU-based service tiers and vCore-based service tiers, see purchasing models.

比较基于 DTU 的服务层级Compare the DTU-based service tiers

选择服务层级首要考虑的是业务连续性、存储和性能需求。Choosing a service tier depends primarily on business continuity, storage, and performance requirements.

基本Basic StandardStandard 高级Premium
目标工作负荷Target workload 开发和生产Development and production 开发和生产Development and production 开发和生产Development and production
运行时间 SLAUptime SLA 99.99%99.99% 99.99%99.99% 99.99%99.99%
最大备份保留期Maximum backup retention 7 天7 days 35 天35 days 35 天35 days
CPUCPU Low 低、中、高Low, Medium, High 中、高Medium, High
IOPS(近似) *IOPS (approximate)* 每个 DTU 1-4 IOPS1-4 IOPS per DTU 每个 DTU 1-4 IOPS1-4 IOPS per DTU 每个 DTU 25 IOPS25 IOPS per DTU
IO 延迟(近似)IO latency (approximate) 5 毫秒(读取),10 毫秒(写入)5 ms (read), 10 ms (write) 5 毫秒(读取),10 毫秒(写入)5 ms (read), 10 ms (write) 2 毫秒(读取/写入)2 ms (read/write)
列存储索引Columnstore indexing 空值N/A S3 及更高版本S3 and above 支持Supported
内存中 OLTPIn-memory OLTP 空值N/A 空值N/A 支持Supported

* 针对数据文件的所有读取和写入 IOPS,包括后台 IO(检查点和惰性编写器)* All read and write IOPS against data files, including background IO (checkpoint and lazy writer)


基本、S0、S1 和 S2 服务目标提供的 vCore (CPU) 不到一个。The Basic, S0, S1 and S2 service objectives provide less than one vCore (CPU). 对于 CPU 密集型工作负载,建议使用 S3 或更高的服务目标。For CPU-intensive workloads, a service objective of S3 or greater is recommended.

在基本、S0 和 S1 服务目标中,数据库文件存储在 Azure 标准存储中,该存储使用基于硬盘驱动器 (HDD) 的存储介质。In the Basic, S0, and S1 service objectives, database files are stored in Azure Standard Storage, which uses hard disk drive (HDD)-based storage media. 这些服务目标最适合用于对性能变化不太敏感的开发、测试和其他不频繁访问的工作负载。These service objectives are best suited for development, testing, and other infrequently accessed workloads that are less sensitive to performance variability.


若要查看数据库或弹性池的实际资源调控限制,请查询 sys.dm_user_db_resource_governance 视图。To see actual resource governance limits for a database or elastic pool, query the sys.dm_user_db_resource_governance view.

单一数据库 DTU 和存储限制Single database DTU and storage limits

单一数据库的计算大小以数据库事务单位 (DTU) 表示,弹性池则以弹性数据库事务单位 (eDTU) 表示。Compute sizes are expressed in terms of Database Transaction Units (DTUs) for single databases and elastic Database Transaction Units (eDTUs) for elastic pools. 有关 DTU 和 eDTU 的更多信息,请参阅基于 DTU 的购买模型For more on DTUs and eDTUs, see DTU-based purchasing model.

基本Basic StandardStandard 高级Premium
最大存储大小Maximum storage size 2 GB2 GB 1 TB1 TB 4 TB4 TB
最大 DTUMaximum DTUs 55 30003000 40004000


在某些情况下,可能需要收缩数据库来回收未使用的空间。Under some circumstances, you may need to shrink a database to reclaim unused space. 有关详细信息,请参阅管理 Azure SQL 数据库中的文件空间For more information, see Manage file space in Azure SQL Database.

弹性池 eDTU、存储和共用数据库限制Elastic pool eDTU, storage, and pooled database limits

基本Basic 标准Standard 高级Premium
每个数据库的最大存储大小Maximum storage size per database 2 GB2 GB 1 TB1 TB 1 TB1 TB
每个池的最大存储大小Maximum storage size per pool 156 GB156 GB 4 TB4 TB 4 TB4 TB
每个数据库的最大 eDTU 数Maximum eDTUs per database 55 30003000 40004000
每个池的最大 eDTU 数Maximum eDTUs per pool 16001600 30003000 40004000
每个池的数据库数目上限Maximum number of databases per pool 500500 500500 100100


在某些情况下,可能需要收缩数据库来回收未使用的空间。Under some circumstances, you may need to shrink a database to reclaim unused space. 有关详细信息,请参阅管理 Azure SQL 数据库中的文件空间For more information, see manage file space in Azure SQL Database.

DTU 基准DTU Benchmark

使用模拟真实数据库工作负荷的基准检验校准与每个 DTU 度量值相关的物理特性(CPU、内存、IO)。Physical characteristics (CPU, memory, IO) associated to each DTU measure are calibrated using a benchmark that simulates real-world database workload.

将基准检验结果与实际数据库性能进行关联Correlating benchmark results to real world database performance

请务必了解,所有基准检验只具有代表性和指示性。It is important to understand that all benchmarks are representative and indicative only. 使用基准检验应用程序完成的事务率不会与使用其他应用程序可能完成的事务率相同。The transaction rates achieved with the benchmark application will not be the same as those that might be achieved with other applications. 基准检验包含不同事务类型的集合,这些事务针对包含一系列表和数据类型的架构运行。The benchmark comprises a collection of different transaction types run against a schema containing a range of tables and data types. 虽然基准检验执行普遍适用于所有 OLTP 工作负荷的相同基本操作,但它并不代表任何特定类别的数据库或应用程序。While the benchmark exercises the same basic operations that are common to all OLTP workloads, it does not represent any specific class of database or application. 基准检验的目标是为在上调或下调计算大小时可预期的数据库相对性能提供合理的指导。The goal of the benchmark is to provide a reasonable guide to the relative performance of a database that might be expected when scaling up or down between compute sizes. 实际上,数据库具有不同的大小和复杂度,会遇到工作负荷的不同组合,并且会以不同方式进行响应。In reality, databases are of different sizes and complexity, encounter different mixes of workloads, and will respond in different ways. 例如,IO 密集型应用程序可能会更快地达到 IO 阈值,或者 CPU 密集型应用程序可能会更快地达到 CPU 限制。For example, an IO-intensive application may hit IO thresholds sooner, or a CPU-intensive application may hit CPU limits sooner. 不能保证任何特定数据库在不断增加的负载下会以与基准检验相同的方式扩展。There is no guarantee that any particular database will scale in the same way as the benchmark under increasing load.

基准检验及其方法会在下面更详细地说明。The benchmark and its methodology are described in more detail below.

基准检验摘要Benchmark summary

基准检验将度量联机事务处理 (OLTP) 工作负荷中最常发生的基本数据库操作组合的性能。The benchmark measures the performance of a mix of basic database operations that occur most frequently in online transaction processing (OLTP) workloads. 尽管在设计基准检验时考虑到了云计算,但已将数据库架构、数据填充和事务设计为广泛代表 OLTP 工作负荷中最常用的基本元素。Although the benchmark is designed with cloud computing in mind, the database schema, data population, and transactions have been designed to be broadly representative of the basic elements most commonly used in OLTP workloads.


架构设计为具有足够的多样性和复杂度以支持各种操作。The schema is designed to have enough variety and complexity to support a broad range of operations. 基准检验针对包含六个表的数据库运行。The benchmark runs against a database comprised of six tables. 这些表分为三个类别:固定大小、缩放和增长。The tables fall into three categories: fixed-size, scaling, and growing. 有两个固定大小表、三个缩放性表和一个增长性表。There are two fixed-size tables; three scaling tables; and one growing table. 固定大小表的行数不变。Fixed-size tables have a constant number of rows. 缩放性表具有一个与数据库性能成正比的基数,但在基准检验期间不会更改。Scaling tables have a cardinality that is proportional to database performance, but doesn't change during the benchmark. 增长性表的大小调整在初始加载时与缩放性表类似,但随后在运行基准检验的过程中随着插入和删除行基数会更改。The growing table is sized like a scaling table on initial load, but then the cardinality changes in the course of running the benchmark as rows are inserted and deleted.

架构包含数据类型(包括整数、数字、字符和日期/时间)的组合。The schema includes a mix of data types, including integer, numeric, character, and date/time. 架构包含主键和辅助键,但不包含任何外键(即,表之间没有任何引用完整性约束)。The schema includes primary and secondary keys, but not any foreign keys - that is, there are no referential integrity constraints between tables.

数据生成程序会生成初始数据库的数据。A data generation program generates the data for the initial database. 使用不同策略生成整数和数字数据。Integer and numeric data is generated with various strategies. 在某些情况下,值在某一范围内随机分布。In some cases, values are distributed randomly over a range. 在其他情况下,会对一组值进行随机排列以确保维持特定分布。In other cases, a set of values is randomly permuted to ensure that a specific distribution is maintained. 文本字段从加权单词列表中生成以产生具有真实感的数据。Text fields are generated from a weighted list of words to produce realistic looking data.

数据库根据“比例因子”调整大小。The database is sized based on a "scale factor." 比例因子(简称为 SF)确定缩放性表和增长性表的基数。The scale factor (abbreviated as SF) determines the cardinality of the scaling and growing tables. 如下面的“用户和步调”部分中所述,数据库大小、用户数和最大性能全都相互成比例缩放。As described below in the section Users and Pacing, the database size, number of users, and maximum performance all scale in proportion to each other.


工作负荷由九种事务类型组成,如下表中所示。The workload consists of nine transaction types, as shown in the table below. 每种事务旨在强调数据库引擎和系统硬件中的特定一组系统特征,与其他事务形成高反差。Each transaction is designed to highlight a particular set of system characteristics in the database engine and system hardware, with high contrast from the other transactions. 此方法可更方便地评估不同组件对总体性能的影响。This approach makes it easier to assess the impact of different components to overall performance. 例如,事务“Read Heavy”将从磁盘生成大量的读取操作。For example, the transaction "Read Heavy" produces a significant number of read operations from disk.

事务类型Transaction Type 说明Description
Read LiteRead Lite SELECT;在内存中;只读SELECT; in-memory; read-only
Read MediumRead Medium SELECT;大多数在内存中;只读SELECT; mostly in-memory; read-only
Read HeavyRead Heavy SELECT;大多数不在内存中;只读SELECT; mostly not in-memory; read-only
Update LiteUpdate Lite UPDATE;在内存中;读写UPDATE; in-memory; read-write
Update HeavyUpdate Heavy UPDATE;大多数不在内存中;读写UPDATE; mostly not in-memory; read-write
Insert LiteInsert Lite INSERT;在内存中;读写INSERT; in-memory; read-write
Insert HeavyInsert Heavy INSERT;大多数不在内存中;读写INSERT; mostly not in-memory; read-write
DeleteDelete DELETE;在内存中和不在内存中的组合;读写DELETE; mix of in-memory and not in-memory; read-write
CPU HeavyCPU Heavy SELECT;在内存中;相对较高的 CPU 负载;只读SELECT; in-memory; relatively heavy CPU load; read-only

工作负荷组合Workload mix

从具有以下整体组合的加权分布中随机选择事务。Transactions are selected at random from a weighted distribution with the following overall mix. 整体组合的读/写比率大约为 2:1。The overall mix has a read/write ratio of approximately 2:1.

事务类型Transaction Type 组合百分比% of Mix
Read LiteRead Lite 3535
Read MediumRead Medium 2020
Read HeavyRead Heavy 55
Update LiteUpdate Lite 2020
Update HeavyUpdate Heavy 33
Insert LiteInsert Lite 33
Insert HeavyInsert Heavy 22
DeleteDelete 22
CPU HeavyCPU Heavy 1010

用户和步调Users and pacing

基准检验工作负荷由一个工具驱动,该工具通过一组连接提交事务以模拟大量并发用户的行为。The benchmark workload is driven from a tool that submits transactions across a set of connections to simulate the behavior of a number of concurrent users. 虽然所有连接和事务都由计算机生成,但为简单起见,我们将这些连接称为“用户”。Although all of the connections and transactions are machine generated, for simplicity we refer to these connections as "users." 虽然每个用户都独立于所有其他用户进行操作,但所有用户都执行相同的步骤循环,如下所示:Although each user operates independently of all other users, all users perform the same cycle of steps shown below:

  1. 建立数据库连接。Establish a database connection.
  2. 重复执行,直到收到退出通知:Repeat until signaled to exit:
    • 随机选择事务(从加权分布中)。Select a transaction at random (from a weighted distribution).
    • 执行所选的事务并测量响应时间。Perform the selected transaction and measure the response time.
    • 等待步调延迟。Wait for a pacing delay.
  3. 关闭数据库连接。Close the database connection.
  4. 退出。Exit.

随机选择了步调延迟(在步骤 2c 中),但却使用了平均值为 1.0 秒的分布。The pacing delay (in step 2c) is selected at random, but with a distribution that has an average of 1.0 second. 因此,每个用户平均每秒最多可以生成一个事务。Thus each user can, on average, generate at most one transaction per second.

缩放规则Scaling rules

用户数由数据库大小(以比例因子单位数表示)确定。The number of users is determined by the database size (in scale-factor units). 每个五个比例系数单位有一个用户。There is one user for every five scale-factor units. 由于步调延迟,一个用户平均每秒最多可以生成一个事务。Because of the pacing delay, one user can generate at most one transaction per second, on average.

例如,比例因子为 500 (SF = 500) 的数据库将具有 100 个用户,并且可以实现的最大速率为 100 TPS。For example, a scale-factor of 500 (SF=500) database will have 100 users and can achieve a maximum rate of 100 TPS. 若要驱动更高的 TPS 速率,需要更多的用户和更大的数据库。To drive a higher TPS rate requires more users and a larger database.

度量持续时间Measurement duration

有效地运行基准检验需要稳定状态度量持续时间至少为 1 小时。A valid benchmark run requires a steady-state measurement duration of at least one hour.


基准检验中的关键指标是吞吐量和响应时间。The key metrics in the benchmark are throughput and response time.

  • 吞吐量是基准检验中至关重要的性能度量值。Throughput is the essential performance measure in the benchmark. 吞吐量以每时间单位的事务数的形式报告,计算所有事务类型。Throughput is reported in transactions per unit-of-time, counting all transaction types.
  • 响应时间是性能可预测性的度量值。Response time is a measure of performance predictability. 响应时间约束因服务等级而异,服务等级越高,响应时间要求越严格,如下所示。The response time constraint varies with class of service, with higher classes of service having a more stringent response time requirement, as shown below.
服务等级Class of Service 吞吐量度量值Throughput Measure 响应时间要求Response Time Requirement
高级Premium 每秒事务数Transactions per second 0.5 秒时达到 95%95th percentile at 0.5 seconds
标准Standard 每分钟事务数Transactions per minute 1.0 秒时达到 90%90th percentile at 1.0 seconds
基本Basic 每小时事务数Transactions per hour 2.0 秒时达到 80%80th percentile at 2.0 seconds

后续步骤Next steps