Azure SQL Database 中的资源管理

适用于：Azure SQL 数据库

本文概述了 Azure SQL 数据库中的资源管理。 还介绍了达到这些资源限制时会发生什么情况，并描述了用于执行这些限制的资源治理机制。

有关单一数据库不同定价层的特定资源限制，请参阅

• 基于 DTU 的单一数据库资源限制
• 基于 vCore 的单一数据库资源限制

有关弹性池资源限制，请参阅：

• 基于 DTU 的弹性池资源限制
• 基于 vCore 的弹性池资源限制

有关 Azure Synapse Analytics 专用 SQL 池限制，请参阅：

• 容量限制
• 内存和并发限制。

考虑以下情况：

• 这些限制适用于新订阅和现有订阅。
• 使用 DTU 购买模型预配的数据库和弹性池也计入 vCore 配额，反之亦然。 消耗的每个 vCore 被视为相当于为服务器级配额消耗的 100 个 DTU。
• 这包括为预配的计算数据库/弹性池配置的 vCore 以及为无服务器数据库配置的“最大 vCore”。
• 可以使用订阅使用情况 - Get REST API 调用来确定订阅的当前 vCore 使用情况。

逻辑服务器限制

资源	限制
每个逻辑服务器的数据库数	5000
某一区域中每个订阅的逻辑服务器默认数量	250
某一区域中每个订阅的逻辑服务器最大数量	250
每个逻辑服务器的最大弹性池数	受限于 DTU 或 vCore 数。 例如，如果每个池是 1000 个 DTU，则一个服务器可以支持 54 个池。

如果达到资源限制，会发生什么

计算 CPU

当数据库计算 CPU 使用率变高时，查询延迟也会增加，查询甚至可能超时。在上述情况下，服务可能对查询排队，并在资源可用时向查询提供资源以用于执行。

当你发现计算利用率很高时，缓解选项包括：

• 提高数据库或弹性池的计算大小，为数据库提供更多计算资源。 请参阅缩放单一数据库资源和缩放弹性池资源。
• 优化查询，以降低每个查询的 CPU 资源利用率。 有关详细信息，请参阅查询优化/提示。

存储

当使用的数据空间达到数据库级别或弹性池级别的最大数据大小限制时，增加数据大小的插入和更新会失败，客户端会收到错误消息。 SELECT 和 DELETE 语句不受影响。

在高级和业务关键服务层中，如果单一数据库或弹性池的数据、事务日志和 tempdb 的总存储消耗超过最大本地存储大小，则客户端也会收到错误消息。 有关详细信息，请参阅存储空间监管。

当你发现存储空间利用率很高时，缓解选项包括：

• 增加数据库或弹性池的最大数据大小，或扩展到具有更高最大数据大小限制的服务目标。 请参阅缩放单一数据库资源和缩放弹性池资源。
• 如果数据库在弹性池内，可选择将数据库移出弹性池，从而避免与其他数据库共享存储空间。
• 收缩数据库来回收未使用的空间。 有关详细信息，请参阅管理 Azure SQL 数据库中的文件空间。
  • 在弹性池中，收缩数据库可为池中的其他数据库提供更多存储空间。
• 检查高空间利用率是否是由永久性版本存储 (PVS) 大小的峰值所造成的。 PVS 是每个数据库的一部分，用于实现加速数据库恢复。 若要确定当前的 PVS 大小，请参阅 PVS 故障排除。 PVS 大小较大的常见原因是事务长时间（数小时）开放，从而无法清理 PVS 中较旧版的行。
• 对于“高级”和“业务关键”服务层中使用大量存储的数据库和弹性池，即使数据库或弹性池中的已用空间低于其最大数据大小限制，也可能会收到空间不足错误。 如果 tempdb 或事务日志文件消耗大量存储空间且即将达到最大本地存储限制，则可能会发生这种情况。 对数据库或弹性池执行故障转移以将 tempdb 重置为其较小的初始大小，或收缩事务日志以减少本地存储消耗。

会话、辅助角色和请求

会话、辅助角色和请求的定义如下：

• 会话表示连接到数据库引擎的过程。
• 请求是查询或批处理的逻辑表示形式。 请求由连接到会话的客户端发出。 一段时间内，可能会在同一个会话中发出多个请求。
• 工作线程（又称为辅助角色或线程）是操作系统线程的逻辑表现形式。 使用并行查询执行计划执行请求时，请求可能有多个辅助角色；使用串行（单线程）执行计划执行请求时，请求可能有单个辅助角色。 辅助角色还需要支持请求外的活动：例如，辅助角色在会话连接时需要处理登录请求。

有关这些概念的详细信息，请参阅线程和任务体系结构指南。

辅助角色的数目上限由服务层级和计算大小决定。 当到达会话或辅助角色上限时，新的请求将被拒绝，客户端将收到错误消息。 虽然应用程序可以轻松地控制连接数，但并行辅助角色数通常更难以估计和控制。 在负荷高峰期，当数据库资源达到上限，辅助角色由于查询运行时间较长、阻塞链大或查询并行度过高而堆积时，这种情况尤其突出。

可以通过以下措施缓解接近或达到辅助角色或会话限制的问题：

• 提高数据库或弹性池的服务层级或计算大小。 请参阅缩放单一数据库资源和缩放弹性池资源。
• 优化查询，降低资源利用率（如果辅助角色数增加的原因是计算资源争用）。 有关详细信息，请参阅查询优化/提示。
• 优化查询工作负载，减少查询受阻的发生次数和持续时间。 有关详细信息，请参阅了解并解决 Azure SQL 阻塞问题。
• 在适当时减少 MAXDOP 设置。

根据服务层和计算大小，查找 Azure SQL 数据库辅助角色和会话的限制：

• 使用 vCore 购买模型的单一数据库的资源限制
• 使用 vCore 购买模型的弹性池的资源限制
• 使用 DTU 购买模型的单一数据库的资源限制
• 使用 DTU 购买模型的弹性池的资源限制

在资源调控错误中详细了解如何排查会话或辅助角色限制的特定错误。

外部连接

通过 sp_invoke_external_rest_endpoint 与外部终结点建立的并发连接数上限为工作线程的 10%，硬上限为最多 150 个工作线程。

内存

与其他资源（CPU、辅助角色、存储）不同，达到内存限制不会对查询性能产生负面影响，也不会导致错误和失败。 如内存管理体系结构指南中所述，按照设计，数据库引擎通常会使用所有可用内存。 内存主要用于缓存数据，以避免速度较慢的存储访问。 因此，较高的内存利用率通常会提高查询性能，因为从内存中读取的速度更快，而从存储中读取的速度更慢。

在数据库引擎启动之后，当工作负荷开始从存储中读取数据时，数据库引擎会积极地在内存中缓存数据。 经过这一初始增长期之后，通常可看到 sys.dm_db_resource_stats 中的 avg_memory_usage_percent 和 avg_instance_memory_percent 列，以及 sql_instance_memory_percent Azure Monitor 指标接近 100%，尤其是对非空闲且不能完全装入内存的数据库而言。

除了数据缓存之外，内存还用于数据库引擎的其他组件。 当有内存需求但所有可用内存已被数据缓存占用时，数据库引擎会缩减数据缓存大小以使内存可供其他组件使用，并会在其他组件释放内存时动态增加数据缓存。

在极少数情况下，要求十分高的工作负载可能会导致内存不足，从而导致内存不足错误。 内存不足错误可能发生在内存使用率介于 0% 和 100% 之间的任何级别。 内存不足错误更有可能发生在具有从比例上来说较小的内存限制的较小计算大小和/或使用更多内存进行查询处理的工作负荷上，例如在密集的弹性池中。

如果你遇到内存不足错误，缓解选项包括：

• 在 sys.dm_os_out_of_memory_events 中查看 OOM 条件的详细信息。
• 提高数据库或弹性池的服务层级或计算大小。 请参阅缩放单一数据库资源和缩放弹性池资源。
• 优化查询和配置以降低内存使用率。 下表中介绍了常见的解决方案。

解决方案	说明
减少内存授予的大小	有关内存授予的详细信息，请参阅了解 SQL Server 内存授予博客文章。 避免过大内存授予的一个常见解决方案是使统计信息保持最新状态。 这样可以更准确地估计查询引擎的内存消耗，避免授予大量内存。 默认情况下，在使用兼容级别 140 和更高级别的数据库中，数据库引擎可能会使用批处理模式内存授予反馈自动调整内存授予大小。 同样，在使用兼容级别 150 及以上级别的数据库中，数据库引擎还使用行模式内存授予反馈进行更常见的行模式查询。 此内置功能有助于避免由于大量内存授予而导致的内存不足错误。
减小查询计划缓存的大小	数据库引擎在内存中缓存查询计划，以避免为每次查询执行编译查询计划。 若要避免由于仅使用一次缓存计划导致的查询计划缓存膨胀，请确保使用参数化查询，并考虑启用 OPTIMIZE_FOR_AD_HOC_WORKLOADS 数据库范围的配置。
减小锁定内存的大小	数据库引擎将内存用于锁定。 如果可能，请避免可能获取大量锁定并导致高锁定内存消耗的大型事务。

用户工作负荷和内部进程的资源消耗量

Azure SQL 数据库需要使用计算资源来实现核心服务功能，例如高可用性和灾难恢复、数据库备份和还原、监视、查询存储、自动优化，等等。对于这些内部进程，系统会使用资源治理机制从总体资源中为其留出有限的一部分资源，使剩余的资源可供用户工作负载使用。 当内部进程不使用计算资源时，系统会将其提供给用户工作负载使用。

用户工作负载和内部流程的 CPU 和内存消耗总量在 sys.dm_db_resource_stats 和 sys.resource_stats 视图中报告，位于 avg_instance_cpu_percent 和 avg_instance_memory_percent 列。 对于池级别的sql_instance_cpu_percent和sql_instance_memory_percent，还会通过 Azure Monitor 指标 sql_instance_cpu_percent 和 sql_instance_memory_percent 报告此数据。

每个数据库中用户工作负载的 CPU 和内存消耗量在 sys.dm_db_resource_stats 和 sys.resource_stats 视图中报告，位于 avg_cpu_percent 和 avg_memory_usage_percent 列。 对于弹性池，将在 sys.elastic_pool_resource_stats 视图（针对历史报告方案）和 sys.dm_elastic_pool_resource_stats（针对实时监视）中报告池级别的资源消耗量。 对于池级别的cpu_percent和弹性池，还会通过 Azure Monitor 指标 cpu_percent 报告用户工作负荷的 CPU 消耗量。

sys.dm_resource_governor_resource_pools_history_ex 和 sys.dm_resource_governor_workload_groups_history_ex 视图报告了用户工作负载和内部流程最近资源消耗的更详细信息。 有关这些视图中提及的资源池和工作负载组的详细信息，请参阅资源治理。 这些视图报告了相关资源池和工作负载组中用户工作负载和特定内部流程的资源利用情况。

用户 CPU 消耗量定义为每个服务目标中用户工作负载限制的一个百分比。 同样，CPU 总消耗量定义为所有工作负载的 CPU 限制的百分比。 由于这两个限制不同，因此用户和总 CPU 消耗量以不同的标度进行度量，并且彼此不直接比较。

如果用户 CPU 消耗量达到 100%，则表示用户工作负载完全使用所选服务目标中可用的 CPU 容量，即使 CPU 总消耗量仍低于 100%。

当 CPU 总消耗量达到 70-100% 范围时，即使用户 CPU 消耗量明显低于 100%，也可能会看到用户工作负载吞吐量保持平稳，但查询延迟增大。 对适度分配的计算资源但相对密集的用户工作负载（例如在密集弹性池中）使用较小的服务目标时，更有可能会发生这种情况。 当内部进程临时需要更多的资源时（例如，在创建数据库的新副本或者备份数据库时），使用较小的服务目标也可能发生这种情况。

同样，当用户 CPU 消耗量达到 70-100% 范围时，即使 CPU 总消耗量可能远远低于其限制，用户工作负载吞吐量将保持平稳，但查询延迟会增大。

当用户 CPU 消耗量或 CPU 总消耗量较高时，缓解选项与计算 CPU 部分中所述相同，包括服务目标增加和/或用户工作负载优化。

资源治理

为了强制实施资源限制，Azure SQL 数据库使用基于 SQL Server Resource Governor 的资源调控实施，后者经过修改和扩展，可在云中运行。 在 SQL 数据库中，多个资源池和工作负载组以及在池和组级别设置的资源限制提供了均衡的数据库即服务。 用户的工作负载和内部工作负载分为单独的资源池和工作负载组。 主副本和可读辅助副本上的用户工作负荷（包括异地副本）可以分类为 SloSharedPool1 资源池和 UserPrimaryGroup.DBId[N] 工作负荷组，其中 [N] 代表数据库 ID 值。 此外，还有多个资源库和各种内部工作负载的工作负载组。

除了使用 Resource Governor 来治理数据库引擎中的资源，Azure SQL 数据库还使用 Windows 作业对象来实现进程级别的资源调控，并使用 Windows 文件服务器资源管理器 (FSRM) 进行存储配额管理。

Azure SQL 数据库资源治理本质上是分层的。 自上而下，使用操作系统资源治理机制和 Resource Governor 在 OS 级别和存储卷级别执行限制，然后使用 Resource Governor 在资源池级别执行限制，再使用 Resource Governor 在工作负载组级别执行限制。 当前数据库或弹性池生效的资源调控限制在 sys.dm_user_db_resource_governance 视图中报告。

数据 I/O 治理

数据 I/O 治理是 Azure SQL 数据库中的一个过程，用于限制对数据库数据文件的读取和写入物理 I/O。 为每个服务级别设置 IOPS 限制，以最大限度地减少“邻近干扰”效应，在多租户服务中提供资源分配公平性，并保持在基础硬件和存储功能范围内。

对于单个数据库，工作负荷组限制适用于针对数据库的所有存储 I/O。 对于弹性池，工作负荷组限制适用于池中的每个数据库。 此外，资源池限制还适用于弹性池的累积 I/O。 在 tempdb 中，I/O 受限于工作负荷组限制，但“基本”、“标准”和“常规用途”服务层级除外，它们应用了更高的 tempdb I/O 限制。 一般来说，由于工作负载组限制低于资源池限制，并且限制 IOPS/吞吐量的速度更快，因此无法通过针对数据库的工作负载（单一或公用）实现资源池限制。 但是，针对同一池中多个数据库的组合工作负荷可能会达到池限制。

例如，如果查询在没有任何 I/O 资源治理的情况下生成 1000 IOPS，但工作负荷组的最大 IOPS 限制设置为 900 IOPS，则该查询无法生成超过 900 的 IOPS。 但是，如果资源池的最大 IOPS 限制设置为 1500 IOPS，并且与资源池关联的所有工作负荷组的总 I/O 超过 1500 IOPS，那么同一查询的 I/O 可能会降低到 900 IOPS 的工作组限制以下。

sys.dm_user_db_resource_governance 视图返回的 IOPS 和吞吐量最大值用作限制/上限，而不是保证。 而且，资源治理并不保证任何特定的存储延迟。 给定用户工作负荷的最佳可实现延迟、IOPS 和吞吐量不仅取决于 I/O 资源治理限制，还取决于所使用的 I/O 大小组合以及基础存储的功能。 SQL 数据库使用的 I/O 操作数在 512 字节和 4 MB 之间变化。 为了强制执行 IOPS 限制，除 Azure 存储中包含数据文件的数据库外，每个 I/O 都会被计入，无论其大小如何。 在这种情况下，大于 256 KB 的 I/O 计为多个 256-KB I/O，以符合 Azure 存储 I/O 数据记录。

对于在 Azure 存储中使用数据文件的基础、标准和通用数据库，如果数据库没有足够的数据文件来累计提供此数量的 IOPS，或者如果数据没有在文件之间均匀分布，再或者基础 Blob 的性能层将 IOPS/吞吐量限制到低于资源治理限制，则可能无法实现 primary_group_max_io 值。 同样，对于因频繁事务提交而产生的小型日志 IO 操作数，由于存在基础 Azure 存储 Blob 的 IOPS 限制，可能无法通过工作负载实现 primary_max_log_rate 值。 对于使用 Azure 高级存储的数据库，Azure SQL 数据库使用足够大的存储 Blob 来获取所需的 IOPS/吞吐量，无论数据库大小如何。 对于较大的数据库，将创建多个数据文件，以提高 IOPS/吞吐量总容量。

资源利用率值（如 sys.dm_db_resource_stats、sys.resource_stats、sys.dm_elastic_pool_resource_stats 和 sys.elastic_pool_resource_stats 视图中报告的 avg_data_io_percent 和 avg_log_write_percent），被计为最大值资源治理限制的百分比。 因此，当资源治理以外的因素限制 IOPS/吞吐量时，即使报告的资源利用率仍低于 100%，IOPS/吞吐量仍可能随着工作负载的增加而趋于平缓和延迟增加。

若要监视每个数据库文件的读取和写入 IOPS、吞吐量和延迟，请使用 sys.dm_io_virtual_file_stats() 函数。 此函数将呈现针对数据库的所有 I/O，包括后台 I/O，此 I/O 没有计入 avg_data_io_percent，但使用基础存储的 IOPS 和吞吐量，并可能会影响观测到的存储延迟。 该函数分别在 io_stall_queued_read_ms 和 io_stall_queued_write_ms 列中报告由于读取和写入的 I/O 资源治理而可能引入的额外延迟。

事务日志速率调控

事务日志速率调控是 Azure SQL 数据库中的一个进程，用于限制批量插入、SELECT INTO 和索引生成等工作负荷的高引入速率。 无论针对数据文件发出多少 IO，系统都会对日志记录生成速率跟踪并实施这些限制，使其保持在亚秒级以下，并限制吞吐量。 事务日志生成速率当前以线性方式扩大到依赖于硬件和依赖于服务层级的程度。

日志速率的设置应该做到可在各种场合下实现并保持该速率，同时，整个系统可以在尽量减轻对用户负载造成的影响的前提下保持其功能。 日志速率调控可确保事务日志备份保留在已发布的可恢复性 SLA 范围内。 此治理还可防止次要副本上的积压工作过多，而次要副本上的积压工作过多可能会导致故障转移期间停机时间长于预期。

向事务日志文件发出的实际物理 IO 不会受到调控或限制。 生成日志记录后，将评估每个操作，以确定是否要将其延迟，从而保持最大所需日志速率（MB/秒）。 将日志记录刷新到存储时不会增大延迟，日志速率治理是在日志速率生成期间应用的。

在运行时实施的实际日志生成速率还受到反馈机制（暂时降低允许的日志速率，使系统保持稳定）的影响。 日志文件空间管理可避免遇到日志空间不足的情况，并且数据复制机制可以暂时降低总体系统限制。

可通过以下 wait 类型（在 sys.dm_exec_requests 和 sys.dm_os_wait_stats 视图中公开）查看日志速率调控器流量的形状：

Wait 类型	说明
LOG_RATE_GOVERNOR	数据库限制
POOL_LOG_RATE_GOVERNOR	池限制
INSTANCE_LOG_RATE_GOVERNOR	实例级限制
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE	反馈控制。高级/业务关键型工作负荷中的可用性组物理复制不会保持
HADR_THROTTLE_LOG_RATE_LOG_SIZE	反馈控制。限制速率可以避免出现日志空间不足的情况
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO	地理复制反馈控制、限制日志速率，以避免高数据延迟和地理辅助系统不可用

当日志速率限制阻碍实现所需的可伸缩性时，请考虑以下选项：

• 纵向扩展到更高的服务级别，以获得服务层级的最大日志速率，或切换到不同的服务层级。 超大规模服务层级为每个数据库提供 100 MB/秒的日志速率，为每个弹性池提供 125 MB/秒的速率，而不考虑所选的服务级别。

  注意

  超大规模弹性池目前处于预览状态。

• 如果加载的数据是暂时性的（例如 ETL 过程中的暂存数据），可将其载入 tempdb（记录最少量的数据）。

• 对于分析方案，请加载到群集的列存储表，或者索引使用了数据压缩的表。 这样可以降低所需的日志速率。 此方法一定会增加 CPU 利用率，仅适用于能够从群集列存储索引或数据压缩受益的数据集。

存储空间治理

在高级和业务关键服务层级中，客户数据（包括数据文件、事务日志文件和 tempdb 文件）存储在托管数据库或弹性池的计算机的本地 SSD 存储中。 本地 SSD 存储提供较高的 IOPS 和吞吐量，以及较低的 I/O 延迟。 除客户数据外，还使用本地存储来存储操作系统、管理软件、监控数据和日志以及系统运行所需的其他文件。

本地存储的大小是有限的，取决于硬件功能（决定了最大本地存储限制），或为客户数据预留的本地存储。 设置此限制是为了最大化客户数据存储，同时确保安全可靠的系统运行。 要查找每个服务目标的最大本地存储值，请参阅单个数据库和弹性池的资源限制文档。

还可以使用以下查询查到此值以及给定数据库或弹性池当前使用的本地存储量：

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();

列	说明
server_name	逻辑服务器名称
database_name	数据库名称
slo_name	服务目标名称，包括硬件代系
user_data_directory_space_quota_mb	最大本地存储空间，以 MB 为单位
user_data_directory_space_usage_mb	数据文件、事务日志文件和 tempdb 文件的当前本地存储消耗，以 MB 为单位。 每五分钟更新一次。

此查询应在用户数据库中执行，而不是在 master 数据库中。 对于弹性池，可以在池中的任何数据库中执行查询。 报告的值适用于整个池。

对于高级和业务关键层级之外的服务层级，本地 SSD 存储还被数据库用于 tempdb 数据库和超大规模 RBPEX 缓存。 随着数据库的创建、删除及其大小的增加或减少，计算机上的本地存储总消耗量会随着时间推移而波动。 如果系统检测到计算机上的可用本地存储不足，并且某个数据库或弹性池有耗尽空间的风险，则系统会将该数据库或弹性池移到具有足够可用本地存储的其他计算机。

此移动以联机方式发生，类似于数据库缩放操作，并具有类似的影响，包括操作结束时的短暂（几秒）故障转移。 此故障转移会终止打开的连接并回退事务，这可能会影响当时使用数据库的应用程序。

由于要将所有数据都复制到其他计算机上的本地存储卷中，因此，移动高级和业务关键服务层级中的较大数据库可能需要大量时间。 在此期间，如果数据库或弹性池或 tempdb 数据库的本地空间消耗增长非常快，则空间耗尽的风险会增加。 该系统以平衡的方式启动数据库移动，以最大限度减少空间耗尽错误，同时避免不必要的故障转移。

tempdb 大小

Azure SQL 数据库中 tempdb 的大小限制取决于购买和部署模型。

若要了解更多信息，请查看以下项的 tempdb 大小限制：

• vCore 购买模型：单一数据库、共用数据库
• DTU 购买模型：单一数据库、共用数据库

以前可用的硬件

本部分包含有关以前可用的硬件的详细信息。

• Gen4 硬件已停用，不可用于预配、纵向扩展或缩减。 将数据库迁移到受支持的硬件代系，实现更广泛的 vCore 和存储可伸缩性、加速网络、最佳 IO 性能和最小延迟。 有关详细信息，请参阅 Azure SQL 数据库上对第 4 代硬件的支持已结束。

可以使用 Azure Resource Graph 资源管理器识别当前使用 Gen4 硬件的所有 Azure SQL 数据库资源，也可以检查 Azure 门户中特定逻辑服务器的资源使用的硬件。

必须至少具有对 Azure 对象或对象组的 read 权限，才能在 Azure Resource Graph 资源管理器中查看结果。

若要使用 Resource Graph 资源管理器来识别仍在使用 Gen4 硬件的 Azure SQL 资源，请执行以下步骤：

1. 转到 Azure 门户。

2. 在搜索框中搜索 Resource graph，然后从搜索结果中选择“Resource Graph 资源管理器”服务。

3. 在查询窗口中，键入以下查询，然后选择“运行查询”：

   resources
   | where type contains ('microsoft.sql/servers')
   | where sku['family'] == "Gen4"
   

4. “结果”窗格显示 Azure 中当前部署的所有使用 Gen4 硬件的资源。

   

若要检查 Azure 中特定逻辑服务器的资源使用的硬件，请执行以下步骤：

1. 转到 Azure 门户。
2. 在搜索框中搜索 SQL servers，然后从搜索结果中选择“SQL Server”，打开“SQL Server”页，并查看所选订阅的所有服务器。
3. 选择所需的服务器，打开服务器的“概述”页。
4. 向下滚动到可用资源，检查使用 Gen4 硬件的资源的“定价层”列。

若要将资源迁移到标准系列硬件，请查看更改硬件。

相关内容

• 有关常规 Azure 限制的相关信息，请参阅 Azure 订阅和服务限制、配额和约束。
• 有关 DTU 和 eDTU 的信息，请参阅 DTU 和 eDTU。
• 有关 tempdb 大小限制的信息，请参阅单一 vCore 数据库、共用 vCore 数据库、单一 DTU 数据库和共用 DTU 数据库。