您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

选择 vCore 或 DTU 购买模型 - Azure SQL 数据库和 SQL 托管实例Choose between the vCore and DTU purchasing models - Azure SQL Database and SQL Managed Instance

适用于: Azure SQL 数据库 Azure SQL 托管实例

使用 Azure SQL 数据库和 Azure SQL 托管实例,可以轻松购买适合你的性能和成本要求的完全托管的平台即服务 (PaaS) 数据库引擎。Azure SQL Database and Azure SQL Managed Instance let you easily purchase a fully managed platform as a service (PaaS) database engine that fits your performance and cost needs. 可以根据选择用于 Azure SQL 数据库的部署模型选择适合需求的购买模型:Depending on the deployment model you've chosen for Azure SQL Database, you can select the purchasing model that works for you:

  • 基于虚拟核心 (vCore) 的购买模型(推荐)。Virtual core (vCore)-based purchasing model (recommended). 此购买模型允许在预配的计算层级和无服务器计算层级之间进行选择。This purchasing model provides a choice between a provisioned compute tier and a serverless compute tier. 使用预配的计算层级时,可以选择始终为工作负荷预配的确切计算资源。With the provisioned compute tier, you choose the exact amount of compute resources that are always provisioned for your workload. 使用无服务器计算层级时,可以指定对计算资源进行的自动缩放(在可配置的计算范围内)。With the serverless compute tier, you specify the autoscaling of the compute resources over a configurable compute range. 使用此计算层级时,还可以根据工作负荷活动自动暂停和恢复数据库。With this compute tier, you can also automatically pause and resume the database based on workload activity. 预配计算层级中单位时间的 vCore 单位价格低于无服务器计算层级中的相应价格。The vCore unit price per unit of time is lower in the provisioned compute tier than it is in the serverless compute tier.
  • 基于数据库事务单位 (DTU) 的购买模型Database transaction unit (DTU)-based purchasing model. 此购买模型针对常见工作负荷提供均衡的捆绑计算和存储包。This purchasing model provides bundled compute and storage packages balanced for common workloads.

有两种购买模型:There are two purchasing models:

以下表格和图表对基于 vCore 和基于 DTU 的购买模型做了对比。The following table and chart compare and contrast the vCore-based and the DTU-based purchasing models:

购买模型Purchasing model 说明Description 最适用于Best for
基于 DTUDTU-based 此模型基于计算、存储和 I/O 资源的捆绑度量。This model is based on a bundled measure of compute, storage, and I/O resources. 单一数据库的计算大小以 DTU 表示,弹性池则以弹性数据库事务单位 (eDTU) 表示。Compute sizes are expressed in DTUs for single databases and in elastic database transaction units (eDTUs) for elastic pools. 有关 DTU 和 eDTU 的详细信息,请参阅什么是 DTU 和 eDTU?For more information about DTUs and eDTUs, see What are DTUs and eDTUs?. 希望获得简单预配置资源选项的客户Customers who want simple, preconfigured resource options
基于 vCorevCore-based 此模型允许单独选择计算和存储资源。This model allows you to independently choose compute and storage resources. 基于 vCore 的购买模型还允许使用适用于 SQL Server 的 Azure 混合权益来节省成本。The vCore-based purchasing model also allows you to use Azure Hybrid Benefit for SQL Server to save costs. 注重灵活性、控制度和透明度的客户Customers who value flexibility, control, and transparency


希望优化并节省云支出?Want to optimize and save on your cloud spending?

Azure 服务是要花钱的。Azure services cost money. Azure 成本管理有助于你设置预算并配置警报,使支出保持在控制范围之内。Azure Cost Management helps you set budgets and configure alerts to keep spending under control. 使用成本管理分析、管理和优化 Azure 成本。Analyze, manage, and optimize your Azure costs with Cost Management. 要了解详细信息,请参阅分析成本快速入门To learn more, see the quickstart on analyzing your costs.

计算成本Compute costs

预配计算成本Provisioned compute costs

在预配计算层级中,计算成本反映针对应用程序预配的总计算容量。In the provisioned compute tier, the compute cost reflects the total compute capacity that is provisioned for the application.

在“业务关键”服务层级中,我们会自动分配至少三个副本。In the Business Critical service tier, we automatically allocate at least three replicas. 为了反映计算资源的此额外分配,在基于 vCore 的购买模型中,“业务关键”服务层级的价格比“常规用途”服务层级的价格高约 2.7 倍。To reflect this additional allocation of compute resources, the price in the vCore-based purchasing model is approximately 2.7 times higher in the Business Critical service tier than it is in the General Purpose service tier. 同理,“业务关键”服务层级中更高的每 GB 存储价格反映了 SSD 存储的更高 IO 限制和更低延迟。Likewise, the higher storage price per GB in the Business Critical service tier reflects the higher IO limits and lower latency of the SSD storage.

“业务关键”服务层级和“常规用途”服务层级的备份存储成本是相同的,因为两者都使用标准存储进行备份。The cost of backup storage is the same for the Business Critical service tier and the General Purpose service tier because both tiers use standard storage for backups.

无服务器计算成本Serverless compute costs

对于无服务器计算层级,请参阅 SQL 数据库无服务器层级,其中介绍了如何定义计算容量以及如何计算成本。For a description of how compute capacity is defined and costs are calculated for the serverless compute tier, see SQL Database serverless tier.

存储费用Storage costs

不同存储类型的计费方式各不相同。Different types of storage are billed differently. 对于数据存储,你要根据所选的最大数据库或池大小支付预配存储的费用。For data storage, you're charged for the provisioned storage based upon the maximum database or pool size you select. 除非减小或增大该最大值,否则费用不会变化。The cost doesn't change unless you reduce or increase that maximum. 备份存储与实例的自动备份相关联,并动态分配。Backup storage is associated with automated backups of your instance and is allocated dynamically. 延长备份保留期会使实例使用的备份存储增大。Increasing your backup-retention period increases the backup storage that's consumed by your instance.

默认情况下,数据库的七天自动备份会复制到读取访问异地冗余存储 (RA-GRS) 标准 Blob 存储帐户。By default, seven days of automated backups of your databases are copied to a read-access geo-redundant storage (RA-GRS) standard Blob storage account. 存储由每周完整备份、每日差异备份和五分钟复制一次的事务日志备份使用。This storage is used by weekly full backups, daily differential backups, and transaction log backups, which are copied every five minutes. 事务日志的大小取决于数据库的变化率。The size of the transaction logs depends on the rate of change of the database. 提供与 100% 数据库大小相等的最小存储量,不收取额外费用。A minimum storage amount equal to 100 percent of the database size is provided at no extra charge. 超出此部分的其他备份存储空间按 GB/月收费。Additional consumption of backup storage is charged in GB per month.

有关存储价格的详细信息,请参阅定价页。For more information about storage prices, see the pricing page.

基于 vCore 的购买模型vCore-based purchasing model

虚拟核心 (vCore) 表示通过一个选项提供的逻辑 CPU,你可以在硬件的层代和硬件的物理特性(例如,核心数、内存、存储大小)之间进行选择。A virtual core (vCore) represents a logical CPU and offers you the option to choose between generations of hardware and the physical characteristics of the hardware (for example, the number of cores, the memory, and the storage size). 基于 vCore 的购买模型提供使用单项资源的灵活性、控制度和透明度,并提供简单明了的方法将本地工作负荷要求转换到云。The vCore-based purchasing model gives you flexibility, control, transparency of individual resource consumption, and a straightforward way to translate on-premises workload requirements to the cloud. 此模型允许根据工作负荷需求来选择计算、内存和存储资源。This model allows you to choose compute, memory, and storage resources based on your workload needs.

在基于 vCore 的购买模型中,可以为 SQL 数据库和 SQL 托管实例选择常规用途业务关键服务层级。In the vCore-based purchasing model, you can choose between the General Purpose and Business Critical service tiers for SQL Database and SQL Managed Instance. 对于单一数据库,还可以选择超大规模服务层级For single databases, you can also choose the Hyperscale service tier.

使用基于 vCore 的购买模型,可以单独选择计算和存储资源、匹配本地性能,以及优化价格。The vCore-based purchasing model lets you independently choose compute and storage resources, match on-premises performance, and optimize price. 在基于 vCore 的购买模型中,费用包括:In the vCore-based purchasing model, you pay for:

  • 计算资源(服务层级 + vCore 数目和内存量 + 硬件层代)。Compute resources (the service tier + the number of vCores and the amount of memory + the generation of hardware).
  • 数据和日志存储的类型与数量。The type and amount of data and log storage.
  • 备份存储 (RA-GRS)。Backup storage (RA-GRS).


计算资源、I/O 以及数据和日志存储按数据库或弹性池收费。Compute resources, I/O, and data and log storage are charged per database or elastic pool. 备份存储按每个数据库收费。Backup storage is charged per each database. 有关 SQL 托管实例费用的详细信息,请参阅 SQL 托管实例For more information about SQL Managed Instance charges, see SQL Managed Instance. 区域限制:有关受支持区域的当前列表,请参阅可用产品(按区域)Region limitations: For the current list of supported regions, see products available by region. 若要在当前不受支持的区域中创建托管实例,请通过 Azure 门户发送支持请求To create a managed instance in a region that currently isn't supported, send a support request via the Azure portal.

如果数据库消耗的 DTU 超过 300 个,则转换为基于 vCore 的购买模型可以降低成本。If your database consumes more than 300 DTUs, converting to the vCore-based purchasing model might reduce your costs. 可以使用所选的 API 或 Azure 门户进行转换,无需停机。You can convert by using your API of choice or by using the Azure portal, with no downtime. 但是,转换不是必需的并且不会自动完成。However, conversion isn't required and isn't done automatically. 如果基于 DTU 的购买模型可以满足性能和业务要求,应继续使用它。If the DTU-based purchasing model meets your performance and business requirements, you should continue using it.

若要从基于 DTU 的购买模型转换为基于 vCore 的购买模型,请参阅从 DTU 迁移到 vCoreTo convert from the DTU-based purchasing model to the vCore-based purchasing model, see Migrate from DTU to vCore.

基于 DTU 的购买模型DTU-based purchasing model

数据库事务单位 (DTU) 表示 CPU、内存、读取和写入的混合度量。A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes. 基于 DTU 的购买模型提供一组预配置的计算资源套件和随附的存储,以促成不同级别的应用程序性能。The DTU-based purchasing model offers a set of preconfigured bundles of compute resources and included storage to drive different levels of application performance. 如果你偏爱预配置套件简易性和每月定价付款,基于 DTU 的模型可能更符合你的需求。If you prefer the simplicity of a preconfigured bundle and fixed payments each month, the DTU-based model might be more suitable for your needs.

在基于 DTU 的购买模型中,可为 Azure SQL 数据库选择“基本”、“标准”或“高级”服务层级。In the DTU-based purchasing model, you can choose between the basic, standard, and premium service tiers for Azure SQL Database. 基于 DTU 的购买模型不适用于 Azure SQL 托管实例。The DTU-based purchasing model isn't available for Azure SQL Managed Instance.

数据库事务单位 (DTU)Database transaction units (DTUs)

对于服务层级内特定计算大小的单一数据库,Azure 保证该数据库(独立于 Azure 云中的任何其他数据库)可获得一定级别的资源。For a single database at a specific compute size within a service tier, Azure guarantees a certain level of resources for that database (independent of any other database in the Azure cloud). 这可以保证提供可预测的性能级别。This guarantee provides a predictable level of performance. 为数据库分配的资源量是以若干 DTU 计算的,是计算资源、存储资源和 I/O 资源的捆绑度量值。The amount of resources allocated for a database is calculated as a number of DTUs and is a bundled measure of compute, storage, and I/O resources.

这些资源之间的比率最初由联机事务处理 (OLTP) 基准工作负荷决定,后者旨在作为典型的真实 OLTP 工作负荷。The ratio among these resources is originally determined by an online transaction processing (OLTP) benchmark workload designed to be typical of real-world OLTP workloads. 工作负荷超过任何以上资源量时,吞吐量将受到限制,从而导致性能下降和超时。When your workload exceeds the amount of any of these resources, your throughput is throttled, resulting in slower performance and time-outs.

工作负荷使用的资源不会影响 Azure 云中其他数据库可用的资源。The resources used by your workload don't impact the resources available to other databases in the Azure cloud. 同样,其他工作负荷使用的资源也不会影响你的数据库可用的资源。Likewise, the resources used by other workloads don't impact the resources available to your database.


DTU 最好地解释了在不同计算大小和服务层级为数据库分配的相对资源量。DTUs are most useful for understanding the relative resources that are allocated for databases at different compute sizes and service tiers. 例如:For example:

  • 提高数据库的计算大小可使 DTU 加倍,这等同于使该数据库可用的资源集增加一倍。Doubling the DTUs by increasing the compute size of a database equates to doubling the set of resources available to that database.
  • 具有 1750 个 DTU 的高级服务层级 P11 数据库提供的 DTU 计算能力是具有 5 个 DTU 的基本服务层级数据库的 350 倍。A premium service tier P11 database with 1750 DTUs provides 350 times more DTU compute power than a basic service tier database with 5 DTUs.

若要更深入地了解工作负荷的资源 (DTU) 消耗,请使用查询性能见解To gain deeper insight into the resource (DTU) consumption of your workload, use query-performance insights to:

  • 按 CPU/持续时间/执行计数确定热门查询,可以对这些查询进行调整来提高性能。Identify the top queries by CPU/duration/execution count that can potentially be tuned for improved performance. 例如,I/O 密集型查询可能会受益于内存中优化技术,以便通过特定的服务层级和计算大小更好地利用可用内存。For example, an I/O-intensive query might benefit from in-memory optimization techniques to make better use of the available memory at a certain service tier and compute size.
  • 深入了解查询详情,查看其文本和资源用量历史记录。Drill down into the details of a query to view its text and its history of resource usage.
  • 访问性能优化建议,这些建议可显示 SQL 数据库顾问执行的操作。Access performance-tuning recommendations that show actions taken by SQL Database Advisor.

弹性数据库事务单位 (eDTU)Elastic database transaction units (eDTUs)

对于始终保持可用的数据库,可将其放入弹性池,而不必提供一组专用资源 (DTU),因为有时可能并不需要这些资源。For databases that are always available, rather than provide a dedicated set of resources (DTUs) that might not always be needed, you can place these databases into an elastic pool. 弹性池中的所有数据库位于单个服务器上,它们共享一个资源池。The databases in an elastic pool are on a single server and share a pool of resources.

弹性池中的共享资源用弹性数据库事务单位 (eDTU) 度量。The shared resources in an elastic pool are measured by elastic database transaction units (eDTUs). 弹性池是一种简单的低成本高效益的解决方案,用于管理使用模式变化很大且不可预测的多个数据库的性能目标。Elastic pools provide a simple, cost-effective solution to manage performance goals for multiple databases that have widely varying and unpredictable usage patterns. 弹性池可保证不出现一个数据库使用池中所有资源的情况,同时确保池中的每个数据库始终可以使用最少量的必需资源。An elastic pool guarantees that all the resources can't be consumed by one database in the pool, while ensuring that each database in the pool always has a minimum amount of necessary resources available.

为池提供的 eDTU 的数量和价格是固定的。A pool is given a set number of eDTUs for a set price. 在弹性池中,单个数据库可在配置的边界内自动缩放。In the elastic pool, individual databases can autoscale within the configured boundaries. 负载较重的数据库消耗较多的 eDTU 来满足需求。A database under a heavier load will consume more eDTUs to meet demand. 负载较轻的数据库消耗较少的 eDTU。Databases under lighter loads will consume fewer eDTUs. 无负载的数据库不消耗任何 eDTU。Databases with no load will consume no eDTUs. 由于资源是为整个池预配的,而不是为每个数据库预配的,因此弹性池可以简化管理任务,使池的预算可预测。Because resources are provisioned for the entire pool, rather than per database, elastic pools simplify your management tasks and provide a predictable budget for the pool.

可以向现有池添加额外的 eDTU,不会造成数据库关闭,对池中的数据库也不会有影响。You can add additional eDTUs to an existing pool with no database downtime and with no impact on the databases in the pool. 同样,可以随时从现有池中删除不再需要的额外 eDTU。Similarly, if you no longer need extra eDTUs, remove them from an existing pool at any time. 还可以随时在池中添加或去除数据库。You can also add databases to or subtract databases from a pool at any time. 若要为其他数据库预留 eDTU,可以限制重负载数据库可用的 eDTU 数目。To reserve eDTUs for other databases, limit the number of eDTUs a database can use under a heavy load. 如果某个数据库的资源用量一直不高,可将其移出池,并使用所需的可预测资源量将它配置为单一数据库。If a database consistently underuses resources, move it out of the pool and configure it as a single database with a predictable amount of required resources.

确定工作负荷所需的 DTU 数Determine the number of DTUs needed by a workload

若要将现有的本地或 SQL Server 虚拟机工作负荷迁移到 SQL 数据库,可以使用 DTU 计算器来估算所需的 DTU 数目。If you want to migrate an existing on-premises or SQL Server virtual machine workload to SQL Database, use the DTU calculator to approximate the number of DTUs needed. 对于现有的 SQL 数据库工作负荷,可以使用查询性能见解来了解数据库资源使用量 (DTU),更深入地了解如何优化工作负荷。For an existing SQL Database workload, use query-performance insights to understand your database-resource consumption (DTUs) and gain deeper insights for optimizing your workload. 使用 sys.dm_db_resource_stats 动态管理视图 (DMV) 可以查看过去一小时的资源消耗。The sys.dm_db_resource_stats dynamic management view (DMV) lets you view resource consumption for the last hour. sys.resource_stats 目录视图显示过去 14 天的资源消耗,不过,五分钟平均值的准确性较低。The sys.resource_stats catalog view displays resource consumption for the last 14 days, but at a lower fidelity of five-minute averages.

确定 DTU 利用率Determine DTU utilization

若要相对于数据库或弹性池的 DTU/eDTU 限制确定 DTU/eDTU 利用率平均百分比,请使用以下公式:To determine the average percentage of DTU/eDTU utilization relative to the DTU/eDTU limit of a database or an elastic pool, use the following formula:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

可从 sys.dm_db_resource_statssys.resource_statssys.elastic_pool_resource_stats DMV 获取此公式的输入值。The input values for this formula can be obtained from sys.dm_db_resource_stats, sys.resource_stats, and sys.elastic_pool_resource_stats DMVs. 换言之,若要相对于数据库或弹性池的 DTU/eDTU 限制确定 DTU/eDTU 利用率百分比,请从 avg_cpu_percentavg_data_io_percentavg_log_write_percent 中拾取给定时间点的最大百分比值。In other words, to determine the percentage of DTU/eDTU utilization toward the DTU/eDTU limit of a database or an elastic pool, pick the largest percentage value from the following: avg_cpu_percent, avg_data_io_percent, and avg_log_write_percent at a given point in time.


数据库的 DTU 限制由 CPU、读取次数、写入次数和数据库的可用内存决定。The DTU limit of a database is determined by CPU, reads, writes, and memory available to the database. 但是,由于 SQL 数据库引擎通常会使用所有可用内存来使其数据缓存提高性能,不管当前数据库负载如何,avg_memory_usage_percent 值通常都接近 100%。However, because the SQL Database engine typically uses all available memory for its data cache to improve performance, the avg_memory_usage_percent value will usually be close to 100 percent, regardless of current database load. 因此,尽管内存确实会间接影响 DTU 限制,但 DTU 利用率公式中并不使用内存值。Therefore, even though memory does indirectly influence the DTU limit, it is not used in the DTU utilization formula.

受益于资源弹性池的工作负荷Workloads that benefit from an elastic pool of resources

池很适合用于低平均资源利用率和相对不频繁的使用高峰的数据库。Pools are well suited for databases with a low resource-utilization average and relatively infrequent utilization spikes. 有关详细信息,请参阅何时应当考虑使用 SQL 数据库弹性池?For more information, see When should you consider a SQL Database elastic pool?.

基于 DTU 的购买模型中的硬件代系Hardware generations in the DTU-based purchasing model

在基于 DTU 的购买模型中,客户不能选择用于其数据库的硬件代系。In the DTU-based purchasing model, customers cannot choose the hardware generation used for their databases. 虽然通常情况下,某个给定的数据库会长时间(通常为多个月)驻留在特定的硬件代系上,但在出现特定事件的情况下,可能必须将数据库转移到另一个硬件代系。While a given database usually stays on a specific hardware generation for a long time (commonly for multiple months), there are certain events that can cause a database to be moved to another hardware generation.

例如,如果数据库需纵向扩展或缩减到另一服务目标、数据中心的当前基础结构正在接近其容量限制,或者当前使用的硬件因寿命已尽而需要停止使用,则可将该数据库转移到另一硬件代系。For example, a database can be moved to a different hardware generation if it's scaled up or down to a different service objective, or if the current infrastructure in a datacenter is approaching its capacity limits, or if the currently used hardware is being decommissioned due to its end of life.

如果将数据库移到另一硬件上,工作负载性能可能会变化。If a database is moved to different hardware, workload performance can change. DTU 模型保证 DTU 基准工作负载的吞吐量和响应时间在数据库移到另一硬件代系时保持大体相同,前提是其服务目标(DTU 数)保持不变。The DTU model guarantees that the throughput and response time of the DTU benchmark workload will remain substantially identical as the database moves to a different hardware generation, as long as its service objective (the number of DTUs) stays the same.

但是,在 Azure SQL 数据库中运行的各种客户工作负载中,对相同服务目标使用不同硬件的影响可能更明显。However, across the wide spectrum of customer workloads running in Azure SQL Database, the impact of using different hardware for the same service objective can be more pronounced. 不同的工作负载将受益于不同的硬件配置和功能。Different workloads will benefit from different hardware configuration and features. 因此,对于 DTU 基准以外的工作负载,如果数据库从一个硬件代系转移到另一个硬件代系,则可能会看到性能差异。Therefore, for workloads other than the DTU benchmark, it's possible to see performance differences if the database moves from one hardware generation to another.

例如,如果应用程序对网络延迟敏感,则其在 Gen5 硬件上的性能会优于在Gen4 硬件上的性能,因为在 Gen5 中使用了加速网络;但是,如果应用程序使用密集读取 IO,则其在 Gen4 硬件上的性能会优于在 Gen5 硬件上的性能,因为 Gen4 上内存与核心的比率更高。For example, an application that is sensitive to network latency can see better performance on Gen5 hardware vs. Gen4 due to the use of Accelerated Networking in Gen5, but an application using intensive read IO can see better performance on Gen4 hardware versus Gen5 due to a higher memory per core ratio on Gen4.

如果客户的工作负载对硬件变化敏感,或者客户希望控制对其数据库的硬件代系的选择,则客户可以在创建和缩放数据库的过程中使用 vCore 模型来选择其首选的硬件代系。Customers with workloads that are sensitive to hardware changes or customers who wish to control the choice of hardware generation for their database can use the vCore model to choose their preferred hardware generation during database creation and scaling. 在 vCore 模型中,会记录单一数据库弹性池的每个硬件代系上每个服务目标的资源限制。In the vCore model, resource limits of each service objective on each hardware generation are documented, for both single databases and elastic pools. 有关 vCore 模型中的硬件代系的详细信息,请参阅硬件代系For more information about hardware generations in the vCore model, see Hardware generations.

常见问题 (FAQ)Frequently asked questions (FAQs)

是否需要将应用程序脱机,才能将基于 DTU 的服务层级转换为基于 vCore 的服务层级?Do I need to take my application offline to convert from a DTU-based service tier to a vCore-based service tier?

否。No. 不需要使应用程序脱机。You don't need to take the application offline. 新服务层级提供简单的在线转换方式,与现有“标准”和“高级”服务层级间的升级和降级过程类似。The new service tiers offer a simple online-conversion method that's similar to the existing process of upgrading databases from the standard to the premium service tier and the other way around. 可以使用 Azure 门户、PowerShell、Azure CLI、T-SQL 或 REST API 启动此转换。You can start this conversion by using the Azure portal, PowerShell, the Azure CLI, T-SQL, or the REST API. 请参阅管理单一数据库管理弹性池See Manage single databases and Manage elastic pools.

是否可以将数据库从使用基于 vCore 的购买模型中的服务层级转换为使用基于 DTU 的购买模型中的服务层级?Can I convert a database from a service tier in the vCore-based purchasing model to a service tier in the DTU-based purchasing model?

是的,可以使用 Azure 门户、PowerShell、Azure CLI、T-SQL 或 REST API 轻松将数据库转换为支持的任何性能目标。Yes, you can easily convert your database to any supported performance objective by using the Azure portal, PowerShell, the Azure CLI, T-SQL, or the REST API. 请参阅管理单一数据库管理弹性池See Manage single databases and Manage elastic pools.

后续步骤Next steps