Azure Database for MySQL - 灵活服务器服务层级
可以在三个服务层级之一中创建 Azure Database for MySQL 灵活服务器实例：可突发、常规用途和业务关键。 基础 VM SKU 区分服务层级使用的 B 系列、D 系列和 E 系列。 计算层和大小的选择决定服务器上可用的内存和 Vcore。 所有服务层级都使用完全相同的存储技术。 所有资源都在 Azure Database for MySQL 灵活服务器实例级别预配。 一个服务器可以有一个或多个数据库。
| 资源/层 | 可突发 | 常规用途 | 业务关键 |
|---|---|---|---|
| VM 系列 | B 系列可突增虚拟机大小 | Dadsv5 系列Ddsv4 系列 | Edsv4/Edsv5 系列*/Eadsv5 系列 |
| vCore 数 | 1、2、4、8、12、16、20 | 2、4、8、16、32、48、64 | 2、4、8、16、20、32、48、64、96 |
| 每个 vCore 的内存 | 变量 | 4 GiB | 8 GiB ** |
| 存储大小 | 20 GiB 到 16 TiB | 20 GiB 到 16 TiB | 20 GiB 到 32 TiB |
| 数据库备份保留期 | 1 到 35 天 | 1 到 35 天 | 1 到 35 天 |
** 64 个和 96 个 vCore 的情况除外，它们分别有 504 GiB 和 672 GiB 内存。
* 在其他 VM 系列中，Ev5 计算在 QPS 和延迟方面表现最佳。 在此处详细了解 Ev5 计算的性能和区域可用性。
灵活服务器服务层级
可以从下表着手来选择计算层。
| 计算层 | 目标工作负荷 |
|---|---|
| 可突发 | 最适合不需要连续使用完整 CPU 的工作负载。 |
| 常规用途 | 大多数业务工作负载。此类工作负载需要均衡的计算和内存以及可缩放的 I/O 吞吐量。 相关示例包括用于托管 Web 和移动应用的服务器，以及其他企业应用程序。 |
| 业务关键 | 高性能数据库工作负荷。此类工作负荷需要内存中性能来实现更快的事务处理速度和更高的并发性。 相关示例包括用于处理实时数据的服务器，以及高性能事务性应用或分析应用。 |
创建服务器后，你可以更改计算层、计算大小和存储大小。 计算缩放需要重启，需要 60-120 秒，而存储缩放则不需要重启。 你还可以独立调高或调低备份保持期。 有关详细信息，请参阅“缩放资源”部分。
服务层级、大小和服务器类型
可以根据层和大小选择计算资源。 这可确定 Vcore 和内存大小。 vCore 表示底层硬件的逻辑 CPU。
可突发
对于“可突发”服务层级，可用服务器类型的详细规格如下。
| 计算大小 | vCore 数 | 物理内存大小 (GiB) | 总内存大小 (GiB) | 支持的最大 IOPS | 最大连接数 | 临时存储 (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
常规用途
对于“常规用途”服务层级，可用服务器类型的详细规格如下
| 计算大小 | vCore 数 | 物理内存大小 (GiB) | 总内存大小 (GiB) | 支持的最大 IOPS | 最大连接数 | 临时存储 (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
业务关键
对于“业务关键”服务层级，可用服务器类型的详细规格如下。
| 计算大小 | vCore 数 | 物理内存大小 (GiB) | 总内存大小 (GiB) | 支持的最大 IOPS | 最大连接数 | 临时存储 (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Azure Database for MySQL 灵活服务器中的内存管理
在 MySQL 中，内存在各种操作（包括查询处理和高速缓存）中发挥着至关重要的作用。 Azure Database for MySQL 灵活服务器可优化 MySQL 服务器进程 (mysqld) 的内存分配，确保其接收足够的内存资源，以实现高效的查询处理、高速缓存、客户端连接管理和线程处理。 详细了解 MySQL 如何使用内存。
物理内存大小 (GB)
下表中的物理内存大小 (GB) 表示 Azure Database for MySQL 灵活服务器上的可用随机存取内存 (RAM)，以千兆字节 (GB) 为单位。
总内存大小 (GB)
Azure Database for MySQL 灵活服务器提供总内存大小 (GB)。 这表示服务器可用的总内存，是物理内存和一定量的临时存储 SSD 组件的组合。 此统一视图旨在简化资源管理，使你只需关注 Azure MySQL 服务器 (mysqld) 进程可用的总内存。 内存百分比 (memory_percent) 指标表示 Azure MySQL 服务器进程 (mysqld) 占用的内存百分比。 该指标是根据总内存大小 (GB) 计算的。 例如，当“内存百分比”指标值显示为 60 时，表示 Azure MySQL 服务器进程占用了 Azure Database for MySQL 灵活服务器上可用总内存大小 (GB) 的 60%。
MySQL 服务器 (mysqld)
Azure MySQL 服务器进程 mysqld 是核心数据库操作引擎。 启动时，它会初始化 InnoDB 缓冲池和线程缓存等所有组件，并根据配置和工作负载需求利用内存。 例如，InnoDB 缓冲池会缓存经常访问的数据和索引，以提高查询执行速度，而线程缓存则会管理客户端连接线程。 了解详细信息。
InnoDB 存储引擎
作为 MySQL 的默认存储引擎，InnoDB 使用内存来缓存经常访问的数据并管理内部结构（例如 innodb 缓冲池和日志缓冲区）。 InnoDB 缓冲池将表数据和索引保存在内存中，以最大程度地减少磁盘 I/O，从而提高性能。 InnoDB 缓冲池大小参数是根据服务器上可用的物理内存大小 (GB) 计算的。 详细了解 Azure Database for MySQL 灵活服务器中可用的 InnoDB 缓冲池的大小。
线程
客户端连接通过连接管理器处理的专用线程进行管理。 这些线程处理客户端交互的身份验证、查询执行和结果检索。 了解详细信息。
若要获取有关可用计算系列的更多详细信息，请参阅 B 系列可突发虚拟机大小、常规用途 Dadsv5 系列Ddsv4 系列和业务关键 Edsv4/Edsv5 系列/Eadsv5 系列的相关 Azure VM 文档。
可突发系列实例的性能限制
注意
对于 B 系列可突发虚拟机大小，如果 VM 已启动/停止或重启，则额度可能会丢失。 有关详细信息，请参阅 B 系列可突增虚拟机大小。
可突发计算层旨在为不需要连续 CPU 满载的工作负载提供经济高效的解决方案。 该层是非生产工作负载的理想选择，例如开发、暂存或测试环境。 可突发计算层的独特功能是能够“突发”，也就是说，当工作负荷需要时，可超出其基线 CPU 性能，最多能够使用 100% 的 vCPU。 这可以通过 CPU 信用模型实现，该模型允许 B 系列实例在 CPU 使用率较低期间累积“CPU 额度”。 然后，可以在 CPU 使用率较高期间使用这些额度，从而使实例能够超出其基本 CPU 性能。
但是，请务必注意，一旦可突发实例耗尽其 CPU 额度，它就会以基本 CPU 性能运行。 例如，Standard_B1ms 的基本 CPU 性能为 20%，即 0.2 Vcore。 假设可突发层服务器运行的工作负载需要比基本级别更高的 CPU 性能，并且耗尽了 CPU 额度。 在这种情况下，服务器可能会遇到性能限制，这最终可能会影响服务器的各种系统操作，例如停止/启动/重启。
注意
对于 B 系列可突发虚拟机大小中的服务器（如 Standard_B1s/Standard_B1ms/Standard_B2s），其主机内存大小相对较小，即使 memory_percent 指标未达到 100%，也可能导致服务器在持续工作负载下崩溃（内存不足）。
由于这种限制，服务器可能会遇到连接问题，系统运行可能会受到影响。 在这种情况下，建议采取的措施是：暂停服务器上的工作负载，根据 B 系列额度银行模式积累额度，或者考虑将服务器扩展到更高的层级，如常规用途或业务关键层级。
因此，虽然可突发计算层为某些类型的工作负载提供了显著的成本和灵活性优势，但不建议用于需要一致 CPU 性能的生产工作负载。 可突发层不支持在 Azure Database for MySQL 灵活服务器功能中创建只读副本的功能，也不支持在 Azure Database for MySQL 灵活服务器功能中创建高可用性概念。 对于此类工作负载和功能，其他计算层（例如常规用途或业务关键层）更合适。
有关 Azure 的 B 系列 CPU 额度模型的详细信息，请参阅 B 系列可突发虚拟机大小和 B 系列 CPU 额度模型。
监视可突发层中的 CPU 额度
监视剩余 CPU 额度对于维持可突发计算层的最佳性能至关重要。 Azure Database for MySQL 灵活服务器提供两个与 CPU 额度相关的重要指标。 触发警报的理想阈值取决于工作负载和性能要求。
监视 Azure Database for MySQL 灵活服务器：此指标指示实例使用的 CPU 额度。 监视此指标可帮助你了解实例的 CPU 使用率模式并有效地管理其性能。
监视 Azure Database for MySQL 灵活服务器：此指标显示实例剩余的 CPU 额度。 监视此指标有助于防止实例由于耗尽其 CPU 额度而导致性能降低。 如果“剩余 CPU 额度”指标低于指定水平（例如，低于总可用额度的 30%），则表示如果当前 CPU 负载继续，实例将面临耗尽其 CPU 额度的风险。
存储
预配的存储是指可供灵活服务器使用的存储容量。 存储用于数据库文件、临时文件、事务日志和 MySQL 服务器日志。 对于可突发和常规用途服务层，存储范围从至少 20 GiB 到 16 TiB 不等。 相反，对于业务关键服务层级，存储支持扩展到 32 TiB。 在所有服务层级中，存储按 1 GiB 的增量缩放，并且可在创建服务器后纵向扩展。
注意
存储只能增加，不能减少。
可以使用存储限制、存储百分比和存储使用的指标在 Azure 门户中（使用 Azure Monitor）监视存储使用情况。 请参阅监视文章了解相关指标。
达到存储限制
当服务器上使用的存储接近预配的上限时，服务器将进入只读模式，以保护服务器上任何丢失的写入。 如果可用存储小于预配存储大小的 5%，则预配存储小于等于 100 GiB 的服务器将标记为只读。 对于预配存储超出 100 GiB 的服务器，当可用存储不到 5 GiB 时，会将该服务器标记为只读。
例如，如果已预配 110 GiB 的存储，而实际使用量超过 105 GiB，则会将服务器标记为只读。 或者，如果已预配 5 GiB 的存储，则当可用存储少于 256 MB 时，服务器会标记为只读。
当服务试图将服务器标记为只读时，会阻止所有新的写入事务请求，系统将继续执行现有的活动事务。 当服务器设置为只读时，所有后续写入操作和事务提交都会失败，但读取查询会继续不间断工作。
若要使服务器退出只读模式，应增加服务器上预配的存储。 可以使用 Azure 门户或 Azure CLI 来完成此操作。 增加后，服务器将准备好再次接受写入事务。
我们建议你 设置警报，以便在服务器存储接近阈值时通知你，从而可以避免进入只读状态。 有关详细信息，请参阅有关如何设置警报的警报文档。
存储自动增长
存储自动增长可防止服务器耗尽存储空间并变为只读。 如果启用了存储自动增长，则存储会在不影响工作负载的情况下自动增长。 默认情况下，会为所有新创建的服务器启用存储自动增长。 对于预配的存储小于 100 GB 的服务器，可用存储小于预配的存储的 10% 时，预配的存储大小就会增加 5 GB。 对于预配存储大于 100 GB 的服务器，可用存储空间小于预配存储大小 10 GB 时，预配存储大小会增加 5%。 适用上面指定的最大存储限制。 刷新服务器实例，以在“计算 + 存储”页面上的“设置”下查看更新后的预配存储。
例如，如果已预配 1000 GB 的存储，而实际使用量超过 990 GB，则服务器存储大小会增加到 1050 GB。 或者，如果已预配 20 GB 的存储，则当可用存储少于 2 GB 时，存储大小会增加到 25 GB。
请记住，存储在自动纵向扩展后无法纵向缩减。
注意
存储自动增长默认为已配置高可用性的服务器启用，无法禁用。
IOPS
Azure Database for MySQL 灵活服务器支持预先预配的 IOPS 和自动缩放 IOPS。 Azure Database for MySQL 灵活服务器中的存储 IOPS 在所有计算大小中，最小 IOPS 为 360，最大 IOPS 由所选计算大小决定。 若要详细了解每个计算大小的最大 IOPS，请参阅此表。
重要
**所有计算大小的最小 IOPS 均为 360
**最大 IOPS 取决于所选的计算大小。
可以使用 Monitor Azure Database for MySQL 灵活服务器指标在 Azure 门户中（使用 Azure Monitor）监视 I/O 消耗量。 如果需要的 IOPS 高于计算的 IOPS 最大值，则需要扩展服务器的计算。
预先预配的 IOPS
Azure Database for MySQL 灵活服务器提供了预先预配的 IOPS，因此可以将特定的 IOPS 数分配给 Azure Database for MySQL 灵活服务器实例。 此设置可确保工作负载的一致且可预测的性能。 使用预先预配的 IOPS，可以为存储卷定义特定的 IOPS 限制，从而保证每秒处理一些请求。 这会产生可靠且有保证的性能级别。 预先预配的 IOPS 让你可以预配超出 IOPS 限制的其他 IOPS。 使用此功能，你可以根据工作负载需求随时增加或减少预配的 IOPS 数。
自动缩放 IOPS
Azure Database for MySQL 灵活服务器的基石是能够实现第 1 层工作负载的最佳性能。 这可以通过使服务器根据工作负载需求无缝自动缩放其数据库服务器的性能 (IO)，从而得到改进。 这是一项可供用户选择加入的功能，允许用户按需缩放 IOPS，无需提前预配 IOPS。 启用自动缩放 IOPS 功能后，现在就可以在 Azure Database for MySQL 灵活服务器中享受无忧的 IO 管理，因为服务器会根据工作负载需求自动向上或向下缩放 IOPS。 自动缩放 IOPS 会自动扩展到每个服务层级和计算大小的“最大支持 IOPS”，如服务层文档中所述。 这可确保无需手动缩放工作即可获得最佳性能。
使用自动缩放 IOPS，你只需为服务器使用的 IO 付费，不再需要预配未充分使用的资源并为其付费，从而节省时间和金钱。 此外，任务关键型第 1 层应用程序可以通过随时为工作负载提供额外的 IO 来实现一致的性能。 自动缩放 IOPS 免除了为 Azure Database for MySQL 灵活服务器客户以最低成本提供最佳性能所需的管理。
动态缩放：自动缩放 IOPS 可根据工作负载的实际需求，动态调整数据库服务器的 IOPS 限制。 这可确保无需手动干预或配置即可获得最佳性能。
处理工作负载峰值：自动缩放 IOPS 使数据库能够无缝处理工作负载峰值或波动，而不会影响应用程序的性能。 此功能可确保即使在高峰使用期间也能保持稳定的响应能力。
成本节省：与指定固定的 IOPS 限制且费用与用量无关的预先配置的 IOPS 不同，自动缩放 IOPS 让你可以只为使用的 I/O 操作数付费。
Backup
该服务会自动备份服务器。 可以选择 1 到 35 天的保持期。 从备份和还原概念文章详细了解备份。
缩放资源
创建服务器之后，可以独立地更改计算层、计算大小（vCore 数和内存）、存储量和备份保持期。 计算大小可以纵向扩展或缩减，备份保持期可以纵向扩展或缩减为 1 到 35 天。 存储大小只能增加。 可以通过门户或 Azure CLI 缩放资源。
注意
存储大小只能增加。 增加后，将不能返回到更小的存储大小。
更改计算层或计算大小时，必须重启服务器，使新的服务器类型生效。 在系统切换到新服务器时，无法建立新的连接，所有未提交的连接将会回退。 此时段不是固定的，但大多数情况下为 60-120 秒。
缩放存储和更改备份保持期是联机操作，无需重启服务器。
价格
有关最新定价信息，请参阅服务的定价页。 若要查看所需配置的具体成本，可以单击 Azure 门户的“计算 + 存储”选项卡，系统就会根据选定的选项显示每月成本。 如果没有 Azure 订阅，可使用 Azure 定价计算器获取估计的价格。 在 Azure 定价计算器网站上，选择“添加项”，展开“数据库”类别，选择“Azure Database for MySQL”和“灵活服务器”作为部署类型以自定义选项 。
如果想要优化服务器成本，可以考虑以下提示：
- 如果计算未充分利用，则缩减计算层或计算大小 (vCore)。
- 如果工作负载不需要连续使用“常规用途”和“业务关键”层中的全部计算容量，请考虑切换到“可突发”计算层。
- 在未使用时停止服务器。
- 如果不需要较长的备份保持期，请缩短备份保持期。