Azure SQL 数据库无服务器计算层(预览版)Azure SQL Database serverless (preview)

Azure SQL 数据库无服务器计算层(预览版)是适用于单一数据库的计算层,可根据工作负荷需求自动缩放,并根据每秒使用的计算资源量计费。Azure SQL Database serverless (preview) is a compute tier for single databases that automatically scales compute based on workload demand and bills for the amount of compute used per second. 此外,当仅对存储计费时,无服务器计算层将在非活动期间自动暂停数据库;当活动返回时,它将自动恢复数据库。The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns.

无服务器计算层Serverless compute tier

适用于单一数据库的无服务器计算层按计算自动缩放范围和自动暂停延迟参数化。The serverless compute tier for a single database is parameterized by a compute autoscaling range and an autopause delay. 这些参数的配置构成了数据库性能体验和计算成本。The configuration of these parameters shape the database performance experience and compute cost.

无服务器计费

性能配置Performance configuration

  • “最小 vCore 数”和“最大 vCore 数”是可配置的参数,用于定义数据库可用的计算容量范围。 The minimum vCores and maximum vCores are configurable parameters that define the range of compute capacity available for the database. 内存和 IO 限制与指定的 vCore 范围成正比。Memory and IO limits are proportional to the vCore range specified.
  • 自动暂停延迟是可配置的参数,用于定义数据库在自动暂停之前必须处于非活动状态的时间段。The autopause delay is a configurable parameter that defines the period of time the database must be inactive before it is automatically paused. 发生下次登录或其他活动时,数据库会自动恢复。The database is automatically resumed when the next login or other activity occurs. 或者,可以禁用自动暂停。Alternatively, autopausing can be disabled.

成本Cost

  • 无服务器数据库的成本是计算成本和存储成本之和。The cost for a serverless database is the summation of the compute cost and storage cost.
  • 如果计算用量介于配置的下限和上限之间,则计算成本基于使用的 vCore 数和内存量。When compute usage is between the min and max limits configured, the compute cost is based on vCore and memory used.
  • 如果计算用量低于配置的下限,则计算成本基于配置的最小 vCore 数和最小内存量。When compute usage is below the min limits configured, the compute cost is based on the min vCores and min memory configured.
  • 暂停数据库后,计算成本将会归零,只会产生存储成本。When the database is paused, the compute cost is zero and only storage costs are incurred.
  • 存储成本的确定方式与在预配计算层中相同。The storage cost is determined in the same way as in the provisioned compute tier.

有关成本的更多详细信息,请参阅计费For more cost details, see Billing.

方案Scenarios

对于具有间歇性、不可预测的使用模式,在空闲使用时间段后的计算预热期间能够容忍一定延迟的单一数据库来说,无服务器是一种高性价比的方案。Serverless is price-performance optimized for single databases with intermittent, unpredictable usage patterns that can afford some delay in compute warm-up after idle usage periods. 相比之下,对于具有较高的平均使用量,并且计算预热期间无法容忍任何延迟的单一数据库或多个数据库,预配计算层是更具性价比的方案。In contrast, the provisioned compute tier is price-performance optimized for single databases or multiple databases in elastic pools with higher average usage that cannot afford any delay in compute warm-up.

适合无服务器计算的场景Scenarios well-suited for serverless compute

  • 具有间歇性、不可预测的使用模式,中间穿插着非活动时段且一段时间内平均计算利用率较低的单一数据库。Single databases with intermittent, unpredictable usage patterns interspersed with periods of inactivity and lower average compute utilization over time.
  • 预配计算层中经常重新缩放的单一数据库;客户更倾向于将计算重新缩放委托到服务。Single databases in the provisioned compute tier that are frequently rescaled and customers who prefer to delegate compute rescaling to the service.
  • 不提供用量历史记录,且在 SQL 数据库中部署之前难以或者无法估算计算大小的新单一数据库。New single databases without usage history where compute sizing is difficult or not possible to estimate prior to deployment in SQL Database.

适合预配计算的场景Scenarios well-suited for provisioned compute

  • 采用较有规律的可预测使用模式,且在一段时间内平均计算利用率较高的单一数据库。Single databases with more regular, predictable usage patterns and higher average compute utilization over time.
  • 不能容忍因较频繁的内存微调或从暂停状态下自动恢复的延迟,而导致需要对性能做出妥协的数据库。Databases that cannot tolerate performance trade-offs resulting from more frequent memory trimming or delay in autoresuming from a paused state.
  • 采用间歇性、不可预测使用模式,可整合到弹性池以提高性价比优化的多个数据库。Multiple databases with intermittent, unpredictable usage patterns that can be consolidated into elastic pools for better price-performance optimization.

与预配计算层的比较Comparison with provisioned compute tier

下表汇总了无服务器计算层和预配计算层之间的区别:The following table summarizes distinctions between the serverless compute tier and the provisioned compute tier:

无服务器计算Serverless compute 预配计算Provisioned compute
数据库使用模式Database usage pattern 间歇性、不可预测的使用模式,在一段时间内的平均计算利用率较低。Intermittent, unpredictable usage with lower average compute utilization over time. 较有规律的使用模式,在一段时间内平均计算利用率较高;或者使用弹性池的多个数据库。More regular usage patterns with higher average compute utilization over time, or multiple databases using elastic pools.
性能管理工作量Performance management effort 较低Lower 较高Higher
计算缩放Compute scaling 自动Automatic 手动Manual
计算响应能力Compute responsiveness 在非活动期后较低Lower after inactive periods 即时Immediate
计费粒度Billing granularity 每秒Per second 每小时Per hour

购买模型和服务层级Purchasing model and service tier

目前,仅 vCore 购买模型中第 5 代硬件上的常规用途层中支持 SQL 数据库无服务器。SQL Database serverless is currently only supported in the General Purpose tier on Generation 5 hardware in the vCore purchasing model.

自动缩放Autoscaling

缩放响应能力Scaling responsiveness

通常,无服务器数据库在具有足够运算能力的计算机上运行,以满足资源需求,而不会中断由最大 vCore 数值设置的限制范围内任何数量的计算请求。In general, serverless databases are run on a machine with sufficient capacity to satisfy resource demand without interruption for any amount of compute requested within limits set by the max vCores value. 有时,如果计算机无法在几分钟内满足资源需求,系统便会自动进行负载均衡。Occasionally, load balancing automatically occurs if the machine is unable to satisfy resource demand within a few minutes. 例如,如果资源需求为 4 个 vCore,但只有 2 个 vCore 可用,则在提供 4 个 vCore 之前,可能需要几分钟时间进行负载均衡。For example, if the resource demand is 4 vCores, but only 2 vCores are available, then it may take up to a few minutes to load balance before 4 vCores are provided. 在负载均衡过程中,除了在连接丢失,操作结束时的一小段时间内,数据库将保持联机状态。The database remains online during load balancing except for a brief period at the end of the operation when connections are dropped.

内存管理Memory management

无服务器数据库的内存回收比预配的计算数据库的内存回收更加频繁。Memory for serverless databases is reclaimed more frequently than for provisioned compute databases. 这种行为对于在无服务器条件下控制成本非常重要,并可能会影响性能。This behavior is important to control costs in serverless and can impact performance.

缓存回收Cache reclamation

与预配的计算数据库不同,CPU 或缓存使用率较低时,系统会从无服务器数据库回收 SQL 缓存中的内存。Unlike provisioned compute databases, memory from the SQL cache is reclaimed from a serverless database when CPU or cache utilization is low.

  • 如果最近使用的缓存条目的总大小在一段时间内低于阈值,缓存利用率将被视为较低。Cache utilization is considered low when the total size of the most recently used cache entries falls below a threshold for a period of time.
  • 触发缓存回收后,目标缓存大小将递减到以前大小的一部分,并且仅当使用率保持较低时才继续回收。When cache reclamation is triggered, the target cache size is reduced incrementally to a fraction of its previous size and reclaiming only continues if usage remains low.
  • 发生缓存回收时,用于选择要逐出的缓存条目的策略与当内存压力较高时适用于预配计算数据库的策略相同。When cache reclamation occurs, the policy for selecting cache entries to evict is the same selection policy as for provisioned compute databases when memory pressure is high.
  • 缓存大小永远不会减至小于最小 vCore 数定义的最小内存限制(可配置)。The cache size is never reduced below the min memory limit as defined by min vCores which can be configured.

在无服务器数据库和预配的计算数据库中,如果使用了所有可用内存,则可能会逐出缓存条目。In both serverless and provisioned compute databases, cache entries may be evicted if all available memory is used.

缓存合成Cache hydration

随着从磁盘中不断提取数据,SQL 缓存也会不断增大,其增长速度与预配的数据库相同。The SQL cache grows as data is fetched from disk in the same way and with the same speed as for provisioned databases. 当数据库处于繁忙状态时,允许缓存无约束增大,但不能超过最大内存限制。When the database is busy, the cache is allowed to grow unconstrained up to the max memory limit.

自动暂停和自动恢复Autopausing and autoresuming

自动暂停Autopausing

如果在自动暂停延迟的时间段内,下面的所有条件均成立,则会触发自动暂停:Autopausing is triggered if all of the following conditions are true for the duration of the autopause delay:

  • 会话数目 = 0Number sessions = 0
  • CPU = 0(对于在用户池中运行的用户工作负荷)CPU = 0 for user workload running in the user pool

如有需要,系统也提供了禁用自动暂停的选项。An option is provided to disable autopausing if desired.

以下功能不支持自动暂停。The following features do not support autopausing. 也就是说,如果使用了以下任意功能,那么无论数据库处于不活动状态的时间长短,数据库都会保持联机状态:That is, if any of the following features are used, then the database remains online regardless of the duration of database inactivity:

  • 异地复制(活动异地复制和自动故障转移组)。Geo-replication (active geo-replication and auto-failover groups).
  • 长期备份保留 (LTR)。Long-term backup retention (LTR).
  • SQL 数据同步中使用的同步数据库。与同步数据库不同,中心数据库和成员数据库支持自动暂停。The sync database used in SQL data sync. Unlike sync databases, hub and member databases support autopausing.
  • 弹性作业中使用的作业数据库。The job database used in elastic jobs.

在部署某些需要数据库联机的服务更新期间,会暂时阻止自动暂停。Autopausing is temporarily prevented during the deployment of some service updates which require the database be online. 在这种情况下,一旦服务更新完成,就会再次允许自动暂停。In such cases, autopausing becomes allowed again once the service update completes.

自动恢复Autoresuming

如果在任何时候,下面的任意条件成立,均会触发自动恢复:Autoresuming is triggered if any of the following conditions are true at any time:

功能Feature 自动恢复触发器Autoresume trigger
身份验证和授权Authentication and authorization 登录Login
威胁检测Threat detection 启用/禁用数据库或服务器级别的威胁检测设置。Enabling/disabling threat detection settings at the database or server level.
修改数据库或服务器级别的威胁检测设置。Modifying threat detection settings at the database or server level.
数据发现和分类Data discovery and classification 添加、修改、删除或查看敏感度标签Adding, modifying, deleting, or viewing sensitivity labels
审核Auditing 查看审核记录。Viewing auditing records.
更新或查看审核策略。Updating or viewing auditing policy.
数据屏蔽Data masking 添加、修改、删除或查看数据屏蔽规则Adding, modifying, deleting, or viewing data masking rules
透明数据加密Transparent data encryption 查看透明数据加密的状况或状态View state or status of transparent data encryption
查询(性能)数据存储Query (performance) data store 修改或查看查询存储设置Modifying or viewing query store settings
自动优化Autotuning 自动优化建议的应用和验证,例如自动索引Application and verification of autotuning recommendations such as auto-indexing
数据库复制Database copying 创建数据库作为副本。Create database as copy.
导出到 BACPAC 文件。Export to a BACPAC file.
SQL 数据同步SQL data sync 按照可配置的时间表或手动执行中心和成员数据库之间的同步Synchronization between hub and member databases that run on a configurable schedule or are performed manually
修改特定的数据库元数据Modifying certain database metadata 添加新的数据库标记。Adding new database tags.
更改最大 vCore 数、最小 vCore 数或自动暂停延迟。Changing max vCores, min vCores, or autopause delay.
SQL Server Management Studio (SSMS)SQL Server Management Studio (SSMS) 使用早于 18.1 的 SSMS 版本并为服务器中的任何数据库打开新的查询窗口,将恢复同一服务器中任何自动暂停的数据库。Using SSMS versions earlier than 18.1 and opening a new query window for any database in the server will resume any auto-paused database in the same server. 如果使用 SSMS 版本 18.1 或更高版本,则不会发生此行为。This behavior does not occur if using SSMS version 18.1 or later.

在部署某些需要数据库联机的服务更新期间,也会触发自动恢复。Autoresuming is also triggered during the deployment of some service updates which require the database be online.

连接Connectivity

如果无服务器数据库处于暂停状态,则首次登录将恢复数据库,并返回一个错误,指出数据库将不可用,错误代码为 40613。If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. 恢复数据库后,必须重新尝试登录以建立连接。Once the database is resumed, the login must be retried to establish connectivity. 具有连接重试逻辑的数据库客户端应该不需要进行修改。Database clients with connection retry logic should not need to be modified.

延迟Latency

自动恢复或自动暂停无服务器数据库的延迟时间通常为 1 分钟自动恢复,1-10 分钟自动暂停。The latency to autoresume and autopause a serverless database is generally order of 1 minute to autoresume and 1-10 minutes to autopause.

载入无服务器计算层Onboarding into serverless compute tier

创建新的数据库,或将现有数据库移动到无服务器计算层中的模式与在预配计算层中创建新的数据库相同,均包含以下两个步骤。Creating a new database or moving an existing database into a serverless compute tier follows the same pattern as creating a new database in provisioned compute tier and involves the following two steps.

  1. 指定服务目标名称。Specify the service objective name. 服务目标规定了服务层、硬件代次和最大 vCore 数。The service objective prescribes the service tier, hardware generation, and max vCores. 下表显示了服务目标选项:The following table shows the service objective options:

    服务目标名称Service objective name 服务层Service tier 硬件代次Hardware generation 最大 vCore 数Max vCores
    GP_S_Gen5_1GP_S_Gen5_1 常规用途General Purpose Gen5Gen5 11
    GP_S_Gen5_2GP_S_Gen5_2 常规用途General Purpose Gen5Gen5 22
    GP_S_Gen5_4GP_S_Gen5_4 常规用途General Purpose Gen5Gen5 44
  2. (可选)指定最小 vCore 数和自动暂停延迟以更改它们的默认值。Optionally, specify the min vCores and autopause delay to change their default values. 下表显示了这些参数可用的值。The following table shows the available values for these parameters.

    参数Parameter 可选的值Value choices 默认值Default value
    最小 vCore 数Min vCores {0.5, 1, 2, 4} 中的任何值,不超过最大 vCore 数Any of {0.5, 1, 2, 4} not exceeding max vCores 0.5 个 vCore0.5 vCores
    自动暂停延迟Autopause delay 最小值:60 分钟(1 小时)Minimum: 60 minutes (1 hour)
    最大值:10080 分钟(7 天)Maximum: 10080 minutes (7 days)
    增量:60 分钟Increments: 60 minutes
    禁用自动暂停:-1Disable autopause: -1
    60 分钟60 minutes

Note

目前不支持使用 T-SQL 将现有数据库移动到无服务器或更改其计算大小,但可以通过 Azure 门户或 PowerShell 完成这些操作。Using T-SQL to move an existing database into serverless or change its compute size is not currently supported but can be done via the Azure portal or PowerShell.

在无服务器计算层中创建新数据库Create new database in serverless compute tier

使用 Azure 门户Use Azure portal

请参阅快速入门:使用 Azure 门户在 Azure SQL 数据库中创建单一数据库See Quickstart: Create a single database in Azure SQL Database using the Azure portal.

使用 PowerShellUse PowerShell

以下示例在无服务器计算层中创建新数据库。The following example creates a new database in the serverless compute tier. 此示例显式指定最小 vCore 数、最大 vCore 数和自动暂停延迟。This example explicitly specifies the min vCores, max vCores, and autopause delay.

New-AzSqlDatabase `
  -ResourceGroupName $resourceGroupName `
  -ServerName $serverName `
  -DatabaseName $databaseName `
  -ComputeModel Serverless `
  -Edition GeneralPurpose `
  -ComputeGeneration Gen5 `
  -MinVcore 0.5 `
  -MaxVcore 2 `
  -AutoPauseDelayInMinutes 720

将数据库从预配的计算层移到无服务器计算层Move database from provisioned compute tier into serverless compute tier

使用 PowerShellUse PowerShell

以下示例将某个数据库从预配的计算层中移入无服务器计算层。The following example moves a database from the provisioned compute tier into the serverless compute tier. 此示例显式指定最小 vCore 数、最大 vCore 数和自动暂停延迟。This example explicitly specifies the min vCores, max vCores, and autopause delay.

Set-AzSqlDatabase `
  -ResourceGroupName $resourceGroupName `
  -ServerName $serverName `
  -DatabaseName $databaseName `
  -Edition GeneralPurpose `
  -ComputeModel Serverless `
  -ComputeGeneration Gen5 `
  -MinVcore 1 `
  -MaxVcore 4 `
  -AutoPauseDelayInMinutes 1440

将数据库从无服务器计算层移到预配的计算层Move database from serverless compute tier into provisioned compute tier

无服务器数据库可以移动到预配计算层中,方法与将预配的计算数据库移动到无服务器计算层相同。A serverless database can be moved into a provisioned compute tier in the same way as moving a provisioned compute database into a serverless compute tier.

修改无服务器配置Modifying serverless configuration

最大 vCore 数Maximum vCores

使用 PowerShellUse PowerShell

在 PowerShell 中结合 MaxVcore 参数使用 Set-AzSqlDatabase 命令修改最大 vCore 数。Modifying the max vCores is performed by using the Set-AzSqlDatabase command in PowerShell using the MaxVcore argument.

最小 vCore 数Minimum vCores

使用 PowerShellUse PowerShell

在 PowerShell 中结合 MinVcore 参数使用 Set-AzSqlDatabase 命令修改最小 vCore 数。Modifying the min vCores is performed by using the Set-AzSqlDatabase command in PowerShell using the MinVcore argument.

自动暂停延迟Autopause delay

使用 PowerShellUse PowerShell

在 PowerShell 中结合 AutoPauseDelayInMinutes 参数使用 Set-AzSqlDatabase 命令修改自动暂停延迟。Modifying the autopause delay is performed by using the Set-AzSqlDatabase command in PowerShell using the AutoPauseDelayInMinutes argument.

监视Monitoring

已使用和计费的资源Resources used and billed

无服务器数据库的资源由应用包、SQL 实例和用户资源池实体封装。The resources of a serverless database are encapsulated by app package, SQL instance, and user resource pool entities.

应用包App package

应用包是数据库最外层的资源管理边界,无论数据库位于无服务器计算层还是预配计算层中。The app package is the outer most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. 应用包包含 SQL 实例和外部服务,这一组合共同限定了所有用户和 SQL 数据库中数据库使用的系统资源的范围。The app package contains the SQL instance and external services that together scope all user and system resources used by a database in SQL Database. 外部服务的示例包括 R 和全文搜索。Examples of external services include R and full-text search. SQL 实例通常决定整个应用包的整体资源利用率。The SQL instance generally dominates the overall resource utilization across the app package.

用户资源池User resource pool

用户资源池是数据库最内层的资源管理边界,无论数据库位于无服务器计算层还是预配计算层中。The user resource pool is the inner most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. 用户资源池限定由 DDL 查询(例如 CREATE 和 ALTER)和 DML 查询(例如 SELECT、INSERT、UPDATE 和 DELETE)生成的用户工作负荷的 CPU 和 IO 范围。The user resource pool scopes CPU and IO for user workload generated by DDL queries such as CREATE and ALTER and DML queries such as SELECT, INSERT, UPDATE, and DELETE. 这些查询通常表示应用包中最重要的使用率比例。These queries generally represent the most substantial proportion of utilization within the app package.

指标Metrics

下表列出了用于监视无服务器数据库应用包和用户池的资源使用情况的指标:Metrics for monitoring the resource usage of the app package and user pool of a serverless database are listed in the following table:

实体Entity 指标Metric 说明Description UnitsUnits
应用包App package app_cpu_percentapp_cpu_percent 应用使用的 vCore 数相对于应用允许的最大 vCore 数的百分比。Percentage of vCores used by the app relative to max vCores allowed for the app. 百分比Percentage
应用包App package app_cpu_billedapp_cpu_billed 报告期内收取的应用计算费用。The amount of compute billed for the app during the reporting period. 在此期间支付的金额是此指标和 vCore 单位价格的乘积。The amount paid during this period is the product of this metric and the vCore unit price.

此指标的值是通过将每秒使用的最大 CPU 和内存使用量按时间进行汇总来得到的。Values of this metric are determined by aggregating over time the maximum of CPU used and memory used each second. 如果使用的量小于按照最小 vCore 数和最小内存量预配的最小量,则按照预配的最小量进行计费。If the amount used is less than the minimum amount provisioned as set by the min vCores and min memory, then the minimum amount provisioned is billed. 为了比较 CPU 与内存以进行计费,可通过将内存量 (GB) 按照每个 vCore 3 GB 进行重新缩放,将内存归一化为以 vCore 数为单位。 In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.
vCore 秒vCore seconds
应用包App package app_memory_percentapp_memory_percent 应用使用的内存相对于应用允许的最大内存的百分比。Percentage of memory used by the app relative to max memory allowed for the app. 百分比Percentage
用户池User pool cpu_percentcpu_percent 用户工作负载使用的 vCore 数相对于用户工作负载允许的最大 vCore 数的百分比。Percentage of vCores used by user workload relative to max vCores allowed for user workload. 百分比Percentage
用户池User pool data_IO_percentdata_IO_percent 用户工作负载使用的数据 IOPS 相对于用户工作负载允许的最大数据 IOPS 的百分比。Percentage of data IOPS used by user workload relative to max data IOPS allowed for user workload. 百分比Percentage
用户池User pool log_IO_percentlog_IO_percent 用户工作负载使用的日志 MB/s 相对于用户工作负载允许的最大日志 MB/s 的百分比。Percentage of log MB/s used by user workload relative to max log MB/s allowed for user workload. 百分比Percentage
用户池User pool workers_percentworkers_percent 用户工作负载使用的工作进程数相对于用户工作负载允许的最大工作进程数的百分比。Percentage of workers used by user workload relative to max workers allowed for user workload. 百分比Percentage
用户池User pool sessions_percentsessions_percent 用户工作负载使用的会话数相对于用户工作负载允许的最大会话数的百分比。Percentage of sessions used by user workload relative to max sessions allowed for user workload. 百分比Percentage

暂停和恢复状态Pause and resume status

在 Azure 门户中,服务器的概述窗格列出了它所包含的数据库的状态。In the Azure portal, the database status is displayed in the overview pane of the server that lists the databases it contains. 数据库状态还显示在该数据库的概述窗格中。The database status is also displayed in the overview pane for the database.

使用以下 PowerShell 命令查询数据库的暂停和恢复状态:Using the following PowerShell command to query the pause and resume status of a database:

Get-AzSqlDatabase `
  -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

资源限制Resource limits

有关资源限制的信息,请参阅无服务器计算层For resource limits, see Serverless compute tier.

计费Billing

计费的计算量是每秒使用的最大 CPU 和内存量。The amount of compute billed is the maximum of CPU used and memory used each second. 如果所用的 CPU 和内存量分别少于最小预配量,则对预配量进行计费。If the amount of CPU used and memory used is less than the minimum amount provisioned for each, then the provisioned amount is billed. 为了比较 CPU 与内存以进行计费,可通过将内存量 (GB) 按照每个 vCore 3 GB 进行重新缩放,将内存归一化为以 vCore 数为单位。In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.

  • 计费的资源:CPU 和内存Resource billed: CPU and memory
  • 计费量:vCore 单位价格 * 最大值(最小 vCore 数、使用的 vCore 数、最小内存量 (GB) * 1/3、使用的内存量量 (GB) * 1/3)Amount billed: vCore unit price * max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • 计费频率:每秒Billing frequency: Per second

vCore 单位价格是每个 vCore 每秒的费用。The vCore unit price in the cost per vCore per second. 请参考 Azure SQL 数据库定价页,获取给定区域的特定单位价格。Refer to the Azure SQL Database pricing page for specific unit prices in a given region.

计费的计算量按以下指标进行公开:The amount of compute billed is exposed by the following metric:

  • 指标:app_cpu_billed(vCore 秒)Metric: app_cpu_billed (vCore seconds)
  • 定义:最大值(最小 vCore 数、使用的 vCore 数、最小内存量(GB) * 1/3、使用的内存量 * 1/3)Definition: max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • 报告频率:每分钟Reporting frequency: Per minute

此数量每秒计算一次,按 1 分钟进行汇总。This quantity is calculated each second and aggregated over 1 minute.

假设为某个无服务器数据库配置了最小 vCore 数 1 和最大 vCore 数 4。Consider a serverless database configured with 1 min vCore and 4 max vCores. 这相当于最小内存大约为 3 GB,最大内存大约为 12 GB。This corresponds to around 3 GB min memory and 12-GB max memory. 假设自动暂停延迟设置为 6 小时,数据库工作负荷在 24 小时内的前 2 小时处于活动状态,在其他时间处于非活动状态。Suppose the auto-pause delay is set to 6 hours and the database workload is active during the first 2 hours of a 24-hour period and otherwise inactive.

在这种情况下,将会计收数据库在前 8 小时内的计算和存储费用。In this case, the database is billed for compute and storage during the first 8 hours. 尽管数据库在 2 小时后处于非活动状态,但仍会根据预配的最小计算资源,计收数据库联机时的后续 6 小时的计算费用。Even though the database is inactive starting after the second hour, it is still billed for compute in the subsequent 6 hours based on the minimum compute provisioned while the database is online. 当数据库暂停时,只会计收 24 小时时段的剩余时间内的存储费用。Only storage is billed during the remainder of the 24-hour period while the database is paused.

更具体地说,此示例中的计算费用的计算方式如下:More precisely, the compute bill in this example is calculated as follows:

时间间隔Time Interval 每秒使用的 vCore 数vCores used each second 每秒使用的 GB 量GB used each second 计费的计算维度Compute dimension billed 时间间隔内计费的 vCore 秒数vCore seconds billed over time interval
0:00-1:000:00-1:00 44 99 使用的 vCore 数vCores used 4 个 vCore * 3600 秒 = 14400 vCore 秒4 vCores * 3600 seconds = 14400 vCore seconds
1:00-2:001:00-2:00 11 1212 使用的内存量Memory used 12 GB * 1/3 * 3600 秒 = 14400 vCore 秒12 GB * 1/3 * 3600 seconds = 14400 vCore seconds
2:00-8:002:00-8:00 00 00 预配的最小内存Min memory provisioned 3 GB * 1/3 * 21600 秒 = 21600 vCore 秒3 GB * 1/3 * 21600 seconds = 21600 vCore seconds
8:00-24:008:00-24:00 00 00 暂停时不计收计算费用No compute billed while paused 0 vCore 秒0 vCore seconds
24 小时内计费的总 vCore 秒Total vCore seconds billed over 24 hours 50400 vCore 秒50400 vCore seconds

假设计算单位的价格为 0.000544 CNY/vCore/秒。Suppose the compute unit price is 0.000544/vCore/second CNY. 那么,此 24 小时时段内的计算费用是计算单位价格和计费 vCore 秒数的积:0.000544/vCore/秒 * 50400 vCore 秒 = 27.4176 元Then the compute billed for this 24-hour period is the product of the compute unit price and vCore seconds billed: 0.000544/vCore/second CNY * 50400 vCore seconds = 27.4176 CNY

可用区域Available regions

无服务器计算层在除以下区域之外的所有区域均可使用:中国东部、中国北部The serverless compute tier is available in all regions except the following regions: China East, China North

后续步骤Next steps