Azure SQL 数据库托管实例资源限制概述Overview Azure SQL Database managed instance resource limits

本文概述了 Azure SQL 数据库托管实例的技术特征和资源限制,并提供了有关如何请求提高这些限制的信息。This article provides an overview of the technical characteristics and resource limits for Azure SQL Database managed instance, and provides information about how to request an increase to these limits.


有关支持的功能和 T-SQL 语句的差异,请参阅功能差异T-SQL 语句支持For differences in supported features and T-SQL statements see Feature differences and T-SQL statement support. 有关单一数据库和托管实例中服务层级之间的一般差异,请参阅服务层级比较For general differencess between service tiers in single database and managed instance see Service tier comparison.

硬件代次特征Hardware generation characteristics

托管实例的某些特征和资源限制取决于底层基础结构和体系结构。Managed instance has characteristics and resource limits that depend on the underlying infrastructure and architecture. Azure SQL 数据库托管实例可部署在两个硬件代次上:Gen4 和 Gen5。Azure SQL Database managed instance can be deployed on two hardware generations: Gen4 and Gen5. 硬件代次具有不同的特征,如下表所述:Hardware generations have different characteristics, as described in the following table:

Gen4Gen4 Gen5Gen5
硬件Hardware Intel E5-2673 v3 (Haswell) 2.4-GHz 处理器、附加的 SSD vCore = 1 PP(物理核心)Intel E5-2673 v3 (Haswell) 2.4-GHz processors, attached SSD vCore = 1 PP (physical core) Intel E5-2673 v4 (Broadwell) 2.3-GHz 处理器、快速 NVMe SSD、vCore=1 LP(超线程)Intel E5-2673 v4 (Broadwell) 2.3-GHz processors, fast NVMe SSD, vCore=1 LP (hyper-thread)
vCore 数目Number of vCores 8、16、24 个 vCore8, 16, 24 vCores 4、8、16、24、32、40、64、80 个 vCore4, 8, 16, 24, 32, 40, 64, 80 vCores
最大内存(内存/核心比)Max memory (memory/core ratio) 每个 vCore 7 GB7 GB per vCore
添加更多 vCore 以获得更多内存。Add more vCores to get more memory.
每个 vCore 5.1 GB5.1 GB per vCore
添加更多 vCore 以获得更多内存。Add more vCores to get more memory.
最大内存中 OLTP 内存Max In-Memory OLTP memory 实例限制:每个 vCore 1 - 1.5 GBInstance limit: 1-1.5 GB per vCore 实例限制:每个 vCore 0.8 - 1.65 GBInstance limit: 0.8 - 1.65 GB per vCore
最大实例预留存储Max instance reserved storage 常规用途:8 TBGeneral Purpose: 8 TB
业务关键:1 TBBusiness Critical: 1 TB
常规用途:8 TBGeneral Purpose: 8 TB
业务关键型 1 TB、2 TB 或 4 TB,具体取决于核心数Business Critical 1 TB, 2 TB, or 4 TB depending on the number of cores


  • 第 4 代硬件即将被淘汰。建议在第 5 代硬件上部署新的托管实例。Gen4 hardware is being phased out. It is recommended to deploy new managed instances on Gen5 hardware.

内存中 OLTP 可用空间In-memory OLTP available space

业务关键服务层级中的内存中 OLTP 空间量取决于 vCore 数和硬件代次。The amount of In-memory OLTP space in Business Critical service tier depends on the number of vCores and hardware generation. 下表列出了可用于内存中 OLTP 对象的内存限制。In the following table are listed limits of memory that can be used for In-memory OLTP objects.

内存中 OLTP 空间In-memory OLTP space Gen5Gen5 Gen4Gen4
4 个 vCore4 vCores 3.14 GB3.14 GB
8 个 vCore8 vCores 6.28 GB6.28 GB 8 GB8 GB
16 个 vCore16 vCores 15.77 GB15.77 GB 20 GB20 GB
24 个 vCore24 vCores 25.25 GB25.25 GB 36 GB36 GB
32 个 vCore32 vCores 37.94 GB37.94 GB
40 个 vCore40 vCores 52.23 GB52.23 GB
64 个 vCore64 vCores 99.9 GB99.9 GB
80 个 vCore80 vCores 131.68 GB131.68 GB

服务层特征Service tier characteristics

托管实例有两个服务层级:常规用途业务关键Managed instance has two service tiers: General Purpose and Business Critical. 这些层级提供不同的功能,如下表中所述。These tiers provide different capabilities, as described in the table below.


“业务关键”服务层级提供可用于只读工作负荷的附加内置实例副本(次要副本)。Business Critical service-tier provides additional built-in copy of instance (secondary replica) that can be used for read-only workload. 如果可以隔离读写查询和只读/分析/报告查询,则能够以相同的价格获得两倍的 vCore 和内存。If you can separate read-write queries and read-only/analytic/reporting queries, you are getting twice vCores and memory for the same price. 次要副本可能滞后于主要实例几秒,因此它旨在卸载不需要确切的当前数据状态的报告/分析工作负荷。Secondary replica might lag few seconds behind the primary instance, so it is designed to offload reporting/analytic workload that don't need exact current state of data. 在下表中,只读查询是在次要副本上执行的查询。In the table below, read-only queries are the queries that are executed on secondary replica.

功能Feature 常规用途General Purpose 业务关键Business Critical
vCore 数目*Number of vCores* 第 4 代:8、16、24Gen4: 8, 16, 24
Gen5:4、8、16、24、32、40、64、80Gen5: 4, 8, 16, 24, 32, 40, 64, 80
Gen4:8、16、24Gen4: 8, 16, 24
Gen5:4、8、16、24、32、40、64、80Gen5: 4, 8, 16, 24, 32, 40, 64, 80
*相同数量的 vCore 专用于只读查询。*Same number of vCores is dedicated for read-only queries.
最大内存Max memory Gen4:56 GB - 168 GB (7GB/vCore)Gen4: 56 GB - 168 GB (7GB/vCore)
Gen5:20.4 GB - 408 GB (5.1GB/vCore)Gen5: 20.4 GB - 408 GB (5.1GB/vCore)
添加更多 vCore 以获得更多内存。Add more vCores to get more memory.
Gen4:56 GB - 168 GB (7GB/vCore)Gen4: 56 GB - 168 GB (7GB/vCore)
Gen5:为读写查询提供 20.4 GB - 408 GB (5.1GB/vCore)Gen5: 20.4 GB - 408 GB (5.1GB/vCore) for read-write queries
为只读查询额外提供 20.4 GB - 408 GB (5.1GB/vCore)。+ additional 20.4 GB - 408 GB (5.1GB/vCore) for read-only queries.
添加更多 vCore 以获得更多内存。Add more vCores to get more memory.
最大实例存储大小(预留)Max instance storage size (reserved) - 2 TB,适用于 4 个 vCore(仅限 Gen5)- 2 TB for 4 vCores (Gen5 only)
- 8 TB,适用于其他大小- 8 TB for other sizes
Gen4:1 TBGen4: 1 TB
- 1 TB,适用于 4、8、16 个 vCore- 1 TB for 4, 8, 16 vCores
- 2 TB(适用于 24 个 vCore)- 2 TB for 24 vCores
- 4 TB(适用于 32、40、64、80 个 vCore)- 4 TB for 32, 40, 64, 80 vCores
最大数据库大小Max database size 不超过当前可用的实例大小(最大为 2 TB - 8 TB,具体取决于 vCore 数)。Up to currently available instance size (max 2 TB - 8 TB depending on the number of vCores). 不超过当前可用的实例大小(最大为 1 TB - 4 TB,具体取决于 vCore 数)。Up to currently available instance size (max 1 TB - 4 TB depending on the number of vCores).
最大 tempDB 大小Max tempDB size 限制为 24 GB/vCore (96 - 1,920 GB) 和当前可用的实例存储大小。Limited to 24 GB/vCore (96 - 1,920 GB) and currently available instance storage size.
添加更多 vCore 以获得更多 TempDB 空间。Add more vCores to get more TempDB space.
日志文件大小限制为 120 GB。Log file size is limited to 120 GB.
不超过当前可用的实例存储大小。Up to currently available instance storage size.
每个实例的数据库数目上限Max number of databases per instance 除非已达到实例存储大小限制,否则为 100。100, unless the instance storage size limit has been reached. 除非已达到实例存储大小限制,否则为 100。100, unless the instance storage size limit has been reached.
每个实例的数据库文件数目上限Max number of database files per instance 除非已达到实例存储大小或 Azure 高级磁盘存储分配空间限制,否则最大为 280。Up to 280, unless the instance storage size or Azure Premium Disk storage allocation space limit has been reached. 除非已达到实例存储大小限制,否则为每个数据库 32,767 个文件。32,767 files per database, unless the instance storage size limit has been reached.
最大数据文件大小Max data file size 限制为当前可用的实例存储大小(最大 2 TB - 8 TB)和 Azure 高级磁盘存储分配空间Limited to currently available instance storage size (max 2 TB - 8 TB) and Azure Premium Disk storage allocation space. 限制为当前可用的实例存储大小(最大为 1 TB - 4 TB)。Limited to currently available instance storage size (up to 1 TB - 4 TB).
最大日志文件大小Max log file size 限制为 2 TB 和当前可用的实例存储大小。Limited to 2 TB and currently available instance storage size. 限制为 2 TB 和当前可用的实例存储大小。Limited to 2 TB and currently available instance storage size.
数据/日志 IOPS(近似值)Data/Log IOPS (approximate) 每个实例最多 30-40 K IOPS*,每个文件 500 - 7500Up to 30-40 K IOPS per instance*, 500 - 7500 per file
*增大文件大小以获取更多 IOPS*Increase file size to get more IOPS
5.5 K - 110 K (1375 IOPS/vCore)5.5 K - 110 K (1375 IOPS/vCore)
添加更多 vCore 以获得更好的 IO 性能。Add more vCores to get better IO performance.
日志写入吞吐量限制(每个实例)Log write throughput limit (per instance) 3 MB/s(每个 vCore)3 MB/s per vCore
最大 22 MB/sMax 22 MB/s
4 MB/秒(每个 vCore)4 MB/s per vCore
最大 48 MB/sMax 48 MB/s
数据吞吐量(近似值)Data throughput (approximate) 100 - 250 MB/s(每个文件)100 - 250 MB/s per file
*增大文件大小以获得更好的 IO 性能*Increase the file size to get better IO performance
无限制。Not limited.
存储 IO 延迟(近似)Storage IO latency (approximate) 5-10 毫秒5-10 ms 1-2 毫秒1-2 ms
内存中 OLTPIn-memory OLTP 不支持Not supported 可用大小取决于 vCore 数Available, size depends on number of vCore
最大会话数Max sessions 3000030000 3000030000
只读副本Read-only replicas 00 1(包含在价格中)1 (included in price)


  • 当前可用实例存储大小是预留实例大小与已用存储空间之差。Currently available instance storage size is the difference between reserved instance size and the used storage space.
  • 与最大存储大小限制进行比较的实例存储大小同时包括用户数据库和系统数据库中的数据和日志文件大小。Both data and log file size in the user and system databases are included in the instance storage size that is compared with the Max storage size limit. 可以使用 sys.master_files 系统视图来确定数据库使用的空间总量。Use sys.master_files system view to determine the total used space by databases. 错误日志不会持久保存,不包括在大小中。Error logs are not persisted and not included in the size. 备份不包括在存储大小中。Backups are not included in storage size.
  • “常规用途”层级上的吞吐量和 IOPS 还取决于不受托管实例显式限制的文件大小Throughput and IOPS on General Purpose tier also depend on the file size that is not explicitly limited by managed instance.
  • 可以使用自动故障转移组在不同的 Azure 区域中创建另一个只读副本。You can create another readable replica in different Azure region using Auto-failover groups.
  • 最大实例 IOPS 取决于工作负荷的文件布局和分布。Max instance IOPS depend on the file layout and distribution of workload. 例如,如果创建 7 个 1 GB 文件(每个文件最大 5K IOPS)和 7 个小文件(小于 128 GB,每个文件 500 IOPS),并且工作负荷可以使用所有文件,则每个实例可以处理 38500 IOPS (7x5000+7x500)。As an example, if you create 7 x 1GB files with max 5K IOPS each and 7 small files (smaller than 128 GB) with 500 IOPS each, you can get 38500 IOPS per instance (7x5000+7x500) if your workload can use all files. 请注意,部分 IOPS 还用于自动备份。Note that some amount of IOPS is also used for auto-backups.

“常规用途”层级中的文件 IO 特征File IO characteristics in General Purpose tier

在“常规用途”服务层级中,每个数据库文件可获得专用的 IOPS 和吞吐量(具体取决于文件大小)。In General Purpose service tier every database file is getting dedicated IOPS and throughput that depends on the file size. 文件越大,获得的 IOPS 和吞吐量越多。Bigger files are getting more IOPS and throughput. 下表显示了数据库文件的 IO 特征:IO characteristics of the database files are shown in the following table:

文件大小File size 0 - 128 GiB0 - 128 GiB 128 - 256 GiB128 - 256 GiB 256 - 512 GiB256 - 512 GiB 0.5 - 1 TiB0.5 - 1 TiB 1 - 2 TiB1 - 2 TiB 2 - 4 TiB2 - 4 TiB 4 - 8 TiB4 - 8 TiB
每个文件的 IOPSIOPS per file 500500 11001100 23002300 50005000 75007500 75007500 12,50012,500
每个文件的吞吐量Throughput per file 100 MiB/秒100 MiB/s 125 MiB/秒125 MiB/s 150 MiB/秒150 MiB/s 200 MiB/秒200 MiB/s 250 MiB/秒250 MiB/s 250 MiB/秒250 MiB/s 480 MiB/秒480 MiB/s

如果注意到某个数据库文件的 IO 延迟较高,或者发现 IOPS/吞吐量即将达到限制,可以通过增大文件大小来提高性能。If you notice high IO latency on some database file or you see that IOPS/throughput is reaching the limit, you might improve performance by increasing the file size.

此外,还存在一些实例级别的限制(例如,最大日志写入吞吐量为 22 MB/秒),因此,可能无法达到日志文件的文件吞吐量,因为即将达到实例吞吐量限制。There are also instance-level limits like max log write throughput 22 MB/s, so you might not be able to reach file throughout on log file because you are reaching instance throughput limit.

支持的区域Supported regions

托管实例只能在支持的区域中创建。Managed instances can be created only in supported regions. 若要在当前不支持的区域中创建托管实例,可以通过 Azure 门户发送支持请求To create a managed instance in a region that is currently not supported, you can send a support request via the Azure portal.

支持的订阅类型Supported subscription types

目前,托管实例仅支持以下订阅类型中的部署:Managed instance currently supports deployment only on the following types of subscriptions:

区域资源限制Regional resource limitations

支持的订阅类型可以包含每个区域的有限数量的资源。Supported subscription types can contain a limited number of resources per region. 托管实例根据订阅类型对每个 Azure 区域实施两种默认限制:Managed instance has two default limits per Azure region depending on a type of subscription type:

  • 子网限制:在单一区域中部署托管实例的子网数上限。Subnet limit: The maximum number of subnets where managed instances are deployed in a single region.
  • vCore 限制:可跨单一区域的所有实例部署的 vCore 数上限。vCore limit: The maximum number of vCores that can be deployed across all instances in a single region. 实例总数不受限制,只要在 vCore 限制内即可。The total number of instances is not limited as long as it is within the vCore limit.


这些限制是默认设置,不是技术限制。These limits are default settings and not technical limitations. 如果在当前区域中需要更多托管实例,可以在 Azure 门户中创建特殊支持请求,以根据需要提高限制。The limits can be increased on-demand by creating a special support request in the Azure portal if you need more managed instances in the current region. 或者,可以在另一个 Azure 区域中创建新的托管实例,而不需要发送支持请求。As an alternative, you can create new managed instances in another Azure region without sending support requests.

下表显示了支持的订阅类型的默认区域限制(可以使用下面所述的支持请求扩展默认限制):The following table shows the default regional limits for supported subscription types (default limits can be extended using support request described below):

订阅类型Subscription type 托管实例子网数目上限Max number of managed instance subnets vCore 单元数目上限*Max number of vCore units*
提前支付Pay-in-advance 33 320320

获取更大的 SQL 托管实例配额Obtaining a larger quota for SQL managed instance

如果在当前区域中需要更多托管实例,请使用 Azure 门户发送扩展配额的支持请求。If you need more managed instances in your current regions, send a support request to extend the quota using the Azure portal. 若要启动获取更大配额的过程,请执行以下操作:To initiate the process of obtaining a larger quota:

  1. 打开“帮助 + 支持”,单击“新建支持请求” 。Open Help + support, and click New support request.


  2. 在新支持请求的“基本信息”选项卡上:On the Basics tab for the new support request:

    • 对于“问题类型”,选择“服务和订阅限制(配额)” 。For Issue type, select Service and subscription limits (quotas).

    • 对于“订阅”,请选择自己的订阅。 For Subscription, select your subscription.

    • 对于“配额类型”,选择“SQL 数据库托管实例” 。For Quota type, select SQL Database Managed Instance.

    • 对于“支持计划”,选择自己的支持计划 。For Support plan, select your support plan.


  3. 单击“下一步” 。Click Next.

  4. 在新支持请求的“问题”选项卡上: On the Problem tab for the new support request:

    • 对于“严重性”,选择问题的严重性级别 。For Severity, select the severity level of the problem.

    • 对于“详细信息”,提供有关问题的其他信息,包括错误消息 。For Details, provide additional information about your issue, including error messages.

    • 对于“文件上传”,附加包含详细信息的文件(最多 4 MB) 。For File upload, attach a file with more information (up to 4 MB).



      有效的请求应包括:A valid request should include:

      • 需要提高订阅限制的区域。Region in which subscription limit needs to be increased.
      • 每个服务层级在配额增加后在现有的子网中所需的 vCore 数目(如果需要扩展任何现有的子网)。Required number of vCores, per service tier in existing subnets after the quota increase (if any of the existing subnets needs to be expanded.
      • 所需的新子网数目,以及每个服务层级在新子网内的 vCore 总数(如果需要在新子网中部署托管实例)。Required number of new subnets and total number of vCores per service tier within the new subnets (if you need to deploy managed instances in new subnets).
  5. 单击“下一步” 。Click Next.

  6. 在新支持请求的“联系人信息”选项卡上,输入首选联系方式(电子邮件或电话)和联系人详细信息。On the Contact Information tab for the new support request, enter preferred contact method (email or phone) and the contact details.

  7. 单击创建Click Create.

后续步骤Next steps