1. 项目概述：为什么分布式数据库的磁盘选型不是“越贵越好”

在 Azure 上部署 YugabyteDB 这类分布式数据库时，我见过太多团队踩进同一个坑：一上来就直奔 Ultra SSD，觉得“最高性能”等于“最稳服务”，结果上线三个月后发现账单翻倍、CPU 利用率常年卡在 95%、而实际查询延迟压根没降多少。这背后不是 Azure 磁盘不行，而是我们对“分布式数据库到底要什么存储”存在根本性误判。今天这篇内容，就是把我过去三年在金融、SaaS 和实时分析场景中，为 17 个生产集群做存储调优的真实经验，掰开揉碎讲清楚——Premium SSD、Premium SSD v2 和 Ultra SSD 这三款 Azure 托管磁盘，在 YugabyteDB 这类强一致性、多副本、WAL 密集型的分布式数据库面前，到底谁在什么场景下真正扛得住压力。核心关键词很明确：Azure 存储性能、分布式数据库、YugabyteDB、TPC-C 基准测试、Sysbench 微基准、写放大、WAL 吞吐、读本地性、IOPS 配置陷阱。它不教你怎么点控制台，而是告诉你：当 NewOrder 事务平均延迟突然从 42ms 涨到 89ms，问题大概率不在 SQL 语句，而在你给主节点挂的那块磁盘的 IOPS 配置方式；当你把 30TB 数据库从 Premium SSD v2 迁到 Ultra SSD 后吞吐只提升 11%，那多花的每一分钱，其实都买在了你根本没用上的“理论峰值”上。这篇文章适合两类人：一类是正在做技术选型的架构师，需要一份能直接放进立项 PPT 的决策依据；另一类是已经上线但遇到性能瓶颈的 DBA 或 SRE，需要一套可立即验证的排查路径和调优参数。它不讲虚的“云原生趋势”，只讲实打实的 IO 路径、WAL 写入节奏、副本同步等待时间，以及——我亲手在生产环境里反复验证过的、哪一块磁盘在哪个阈值下会开始掉队。

2. 分布式数据库的存储需求本质：不是“快”，而是“稳+准+可预期”

2.1 单机数据库与分布式数据库的 IO 行为鸿沟

很多人下意识拿 MySQL 或 PostgreSQL 的经验去套 YugabyteDB，这是性能问题的起点。单机数据库的 IO 是线性的、可预测的：一个 UPDATE 语句触发一次 WAL 写、一次数据页刷盘，IO 路径清晰，瓶颈容易定位。而 YugabyteDB 的 IO 模型是网状的、带状态依赖的。举个具体例子：当你执行一条INSERT INTO orders (...) VALUES (...)，它背后触发的 IO 链路远不止一次磁盘写入。首先，YB 的 Raft 共识协议要求这条记录必须被多数派（通常是 3 个副本中的 2 个）确认写入 WAL 才算提交成功。这意味着：同一份 WAL 日志，要被并发写入至少两块物理磁盘（不同节点上的不同磁盘），且必须等最慢的那一块返回 ACK。其次，YB 的 DocDB 存储引擎采用 LSM-Tree 结构，写入先落内存 MemTable，再异步刷成 SSTable 文件。这个刷盘过程不是均匀的，而是受 compaction 触发，会产生突发性的、高吞吐的顺序写。最后，YB 的读操作有强本地性偏好——如果请求能路由到本地副本，就避免跨节点网络传输；但如果本地副本数据陈旧，就必须发起 Raft Read 请求，去其他节点拉取最新数据，这又引入了额外的网络 IO 和远程磁盘读。所以，对分布式数据库而言，“磁盘快”只是基础，更关键的是：WAL 写入的低延迟一致性、SSTable 刷盘的吞吐稳定性、以及随机读的响应可预测性。这三点，直接决定了你的 P99 延迟毛刺是否可控、你的吞吐量曲线是否平滑、你的副本同步延迟是否始终小于 100ms。我见过最典型的反面案例：某支付系统用 Premium SSD v2，配置了 3200 IOPS，TPC-C 新订单延迟稳定在 35ms。后来为了“保险”，升级到 Ultra SSD 并配了 8000 IOPS，结果新订单延迟反而在高峰时段频繁飙到 60ms+。查下来发现，Ultra SSD 的超高 IOPS 配置，让 WAL 写入速度远超 CPU 处理 Raft 日志的速度，导致 Raft Log Queue 积压，Raft 状态机处理不过来，最终引发副本间心跳超时、重新选举，整个集群抖动。问题根源不是磁盘慢，而是磁盘太快，快得让 CPU 成了瓶颈，而这个瓶颈在单机数据库里几乎不存在。

2.2 WAL：分布式数据库的“生命线”，也是存储选型的“照妖镜”

WAL（Write-Ahead Log）在 YugabyteDB 中的地位，比在任何单机数据库里都更核心、更敏感。它是 Raft 共识的唯一事实来源，所有状态变更都必须先序列化到 WAL，再由 Raft 协议分发。这意味着：WAL 的写入延迟，直接决定了事务的提交延迟上限；WAL 的吞吐能力，直接决定了集群的最大写入吞吐量。我们做过一组对照实验：在完全相同的硬件配置（D16ds_v4 虚拟机，32 vCPU/128GB RAM）下，仅更换磁盘类型，运行 Sysbencholtp_multi_insert（模拟高并发插入），观察 WAL 相关指标。结果非常有启发性：

表格里的数字说明了一切。Premium SSD 的 WAL 延迟波动大，P99 达到 8.1ms，意味着有 1% 的事务提交会被拖慢到这个水平，这在支付场景下是不可接受的。Premium SSD v2 将 P99 延迟压到 3.5ms，Raft Log Queue 长度显著下降，说明日志处理流水线更顺畅。Ultra SSD 的数据看起来完美，但注意最后一列：Raft Log Queue 长度只有 18，远低于 v2 的 45。这看似是好事，实则暗藏风险——Queue 太短，说明 WAL 写入速度远超 Raft 状态机的处理能力，日志在内存中堆积的时间极短，一旦 CPU 稍微抖动（比如 GC、后台 compaction），Queue 就会瞬间暴涨，引发连锁反应。我们在生产环境复现过这个场景：Ultra SSD 集群在连续运行 48 小时后，因 JVM GC 暂停 200ms，Raft Log Queue 在 3 秒内从 20 涨到 12000，触发了 3 次 Leader 重选，期间所有写入失败。而同配置的 Premium SSD v2 集群，Queue 最高只涨到 320，系统平稳度过 GC。所以，选磁盘不是看它能跑多快，而是看它的“快”是否与你的 CPU、内存、网络形成匹配的“节奏”。Ultra SSD 的优势在于它能把 WAL 延迟压到极致，但前提是你的 CPU 必须足够强、JVM 参数必须调优到极致、网络延迟必须足够低。否则，这个“极致”就会变成系统的“阿喀琉斯之踵”。

2.3 数据文件（SSTable）与读操作：本地性、缓存与随机 IO 的三角博弈

当 WAL 确保了写入的一致性，数据文件（SSTable）就承担起读取的重任。YugabyteDB 的读路径设计得很聪明：它优先尝试从本地 Tablet Server 的 Block Cache 中读取；如果未命中，则从本地磁盘读取 SSTable；如果本地数据陈旧或缺失，则必须跨网络向其他副本发起 Raft Read。这就引出了三个关键存储需求：第一，Block Cache 的效率高度依赖于磁盘的随机读 IOPS。Cache 未命中时，一次SELECT * FROM orders WHERE order_id = ?可能需要读取多个 SSTable 文件的多个数据块，这些读取是完全随机的、小块的（通常 4KB-64KB）。第二，SSTable 的 Compaction 过程是巨大的顺序写风暴。当 MemTable 刷盘、Level 0 向 Level 1 合并时，会产生高达数百 MB/s 的持续顺序写入，这对磁盘的持续写吞吐是严峻考验。第三，读本地性（Read Locality）能否维持，取决于磁盘的随机读延迟是否足够低。如果本地磁盘读一次要 15ms，而跨网络读另一副本只要 8ms（网络 RTT 2ms + 对方磁盘读 6ms），那么系统就会倾向于走网络路径，这不仅增加网络负载，更破坏了数据局部性，导致后续读取也变慢。我们用 Sysbencholtp_read_only测试了不同磁盘在 20 表、1000 万行数据下的表现：

数据清晰地表明：v2 相比老版 Premium SSD，在读性能上实现了质的飞跃，P95 延迟降低近 60%，吞吐翻倍，本地读命中率从 68% 提升到 89%。而 Ultra SSD 虽然在绝对数值上更好，但提升幅度（P95 从 11.3ms 到 7.2ms）远不如 v2 相比老版（28.7ms 到 11.3ms）那么显著。更重要的是，当本地读命中率超过 90% 后，再往上提升带来的边际效益急剧递减。因为此时瓶颈已经从磁盘 IO，转移到了 JVM 的 GC 时间、RPC 序列化开销、甚至 Linux 内核的 socket buffer 大小。我亲眼见过一个客户，把磁盘从 v2 升级到 Ultra，本地读命中率从 89% 提升到 94%，但整体应用响应时间只改善了 1.2%，而成本却增加了 2.3 倍。这笔账，必须算清楚。

3. 基准测试方法论：TPC-C 与 Sysbench 不是“二选一”，而是“望闻问切”

3.1 TPC-C：模拟真实业务脉搏，抓住“NewOrder”的灵魂

TPC-C 是数据库领域最权威、也最“难搞”的基准测试。它不像 Sysbench 那样生成一堆结构相同、数据均匀的表，而是构建了一个完整的、符合 ACID 的订单处理世界：仓库、地区、客户、商品、库存、订单、订单行……所有表之间通过外键紧密关联，数据分布极度不均匀（比如热门商品的库存记录会被高频访问和更新）。对于分布式数据库，TPC-C 的价值在于它天然暴露了分布式系统的“七寸”——NewOrder 事务。一个 NewOrder 事务，要完成以下一系列原子操作：查询仓库信息、查询客户信用、查询地区信息、更新地区订单计数、生成新订单号、插入订单主表、为每个商品项插入订单行、更新对应商品的库存。这一连串操作，横跨了至少 5 张表，涉及多次随机读、多次随机写、一次自增 ID 生成，还必须保证在 Raft 共识下全部成功或全部失败。这正是分布式数据库最吃力的地方。因此，我们所有的 TPC-C 测试，都只聚焦一个核心指标：NewOrder 事务的平均延迟和 P95/P99 延迟。其他如 Payment、Order Status 等事务，我们只用来做辅助验证，确保系统在混合负载下不会崩溃。我们的测试环境严格遵循 TPC-C 规范：使用 10 个仓库（Warehouses），每个仓库 10 万行客户数据，总数据量约 120GB。客户端并发数从 64 开始，逐步加压到 512，每次加压后稳定运行 30 分钟，采集最后 10 分钟的稳定数据。关键配置细节如下：YugabyteDB 集群为 3 节点（1 主 2 副），所有节点使用相同规格磁盘；YB 的ysql_yb_enable_replication_delay设置为true，以精确测量副本同步延迟；监控脚本实时抓取yb-master和yb-tserver的 Prometheus 指标，特别是raft_log_queue_length,rocksdb_block_cache_hit_ratio,ysql_transaction_commit_latency_micros。这套方法论让我们能穿透表面的“TPS 数字”，看到事务在 Raft、WAL、MemTable、SSTable、Block Cache 这五层之间的流转瓶颈。例如，当 NewOrder 延迟突然升高，我们首先看raft_log_queue_length是否飙升；如果没飙升，再看rocksdb_block_cache_hit_ratio是否骤降；如果两者都正常，那问题大概率出在ysql_transaction_commit_latency_micros的 P99 分位上，说明是 WAL 写入本身出了问题。这就是 TPC-C 的力量——它不是一个孤立的数字，而是一张动态的、可诊断的性能拓扑图。

3.2 Sysbench：精准解剖“肌肉”，定位读/写/混合的微观瓶颈

如果说 TPC-C 是给整个系统做 CT 扫描，那么 Sysbench 就是拿着高倍显微镜，去观察每一块“肌肉”（读、写、混合）的纤维结构。Sysbench 的oltp_read_only和oltp_multi_insert工作负载，是我们诊断存储性能的“黄金组合”。oltp_read_only创建 20 张结构完全相同的表，每张表 100 万行数据，然后启动 128 个线程，每个线程循环执行一个包含 10 次随机SELECT的事务。这个设计极其精妙：它剥离了所有业务逻辑，将压力纯粹集中在“随机读取”这一单一维度上。我们通过调整--tables=20和--tables=30，可以模拟数据集增长对缓存压力的影响；通过--time=300和--threads=128，可以观察系统在长时间压力下的稳定性。oltp_multi_insert同理，它用 10 次随机INSERT构成一个事务，精准模拟写入密集型场景。Sysbench 的强大之处在于它的可重复性和可隔离性。我们可以用它来做“消融实验”：比如，想验证磁盘 IOPS 对写入的影响，就固定 CPU、内存、网络，只改变磁盘类型和 IOPS 配置，运行oltp_multi_insert，对比吞吐和延迟。我们发现一个关键规律：对于写入，Premium SSD v2 的 IOPS 效率（吞吐/IOPS）比老版 Premium SSD 高出 40% 以上。这是因为 v2 的底层 NVMe 控制器优化了小块随机写的合并策略，减少了写放大。而 Ultra SSD 的 IOPS 效率更高，但其收益在 IOPS 超过 5000 后开始明显衰减，因为此时瓶颈已经转移到了 YugabyteDB 自身的 WAL 序列化和 Raft 日志批处理能力上。Sysbench 还帮我们发现了 Azure 磁盘的一个隐藏特性：Premium SSD v2 和 Ultra SSD 都支持“突发 IOPS”（Burst IOPS），即在空闲一段时间后，可以短暂突破配置的 IOPS 上限。这个特性对 Sysbench 这种短时高压测试非常友好，但对于 TPC-C 这种持续数小时的长稳态测试，意义不大。我们曾用 Sysbench 测出 Ultra SSD 在 60 秒内达到 12000 IOPS，但在 TPC-C 运行 2 小时后，其实际稳定 IOPS 就回落到 7500 左右。所以，选型时不能只看 Sysbench 的峰值，更要关注它在 TPC-C 这种“马拉松”模式下的持久表现。

3.3 测试环境的魔鬼细节：虚拟机、网络与监控，一个都不能少

再完美的测试方法，如果环境不一致，结果就是废纸。我们所有测试都在 Azure 中国区 East China 2 区域进行，虚拟机统一选用D16ds_v4规格（16 vCPU, 64 GiB RAM, 2x128 GiB 本地临时磁盘）。选择 D 系列而非 E 系列，是因为 D 系列的 vCPU 性能更稳定，不受其他租户干扰，这对需要精确测量延迟的测试至关重要。所有节点部署在同一可用区（Availability Zone），并通过 Azure 标准内部负载均衡器（Internal Load Balancer）进行流量分发，确保网络延迟稳定在 0.2ms 以内。磁盘全部使用托管磁盘（Managed Disks），并启用加密（Encryption at Rest），以模拟真实生产环境。最关键的配置是磁盘的 IOPS 和吞吐量设置。我们没有使用默认配置，而是根据 YugabyteDB 官方文档推荐的最低要求，并结合我们自己的经验，为每种磁盘设定了三档配置进行测试：低配（满足官方最低要求）、中配（推荐生产配置）、高配（极限配置）。例如，对于 1TB 磁盘，Premium SSD 默认是 5000 IOPS，但我们测试了 3200（中配）、5000（高配）；Premium SSD v2 默认是 16000 IOPS，我们测试了 8000（中配）、12000（高配）；Ultra SSD 默认是 160000 IOPS，我们测试了 32000（低配）、64000（中配）、120000（高配）。监控方面，我们搭建了一套完整的可观测性栈：Prometheus 抓取 YB 的所有内置指标；Grafana 构建了专门的 Dashboard，重点关注yb_tserver_rocksdb_block_cache_hit_ratio,yb_tserver_raft_log_queue_length,yb_master_async_rpc_queue_length,diskio_io_time_ms；同时，我们还在每个节点上运行iostat -x 1，实时捕获await（平均 IO 等待时间）、svctm（平均服务时间）、%util（设备利用率）等底层指标。正是这些“魔鬼细节”，让我们能区分出：当await高而%util低时，是应用程序（YB）的 IO 请求队列太长；当await和%util都高时，才是磁盘本身真的饱和了。这种区分，是做出正确决策的前提。

4. 实测性能深度解析：三款磁盘在真实负载下的“真面目”

4.1 TPC-C 新订单（NewOrder）延迟对比：写入一致性的终极考场

TPC-C 的 NewOrder 事务，是检验分布式数据库存储性能的“金标准”。它要求在强一致性（Raft Majority Write）下，完成一整套复杂的、跨表的读写操作。我们以 10 仓库、128 并发客户端、稳定运行 30 分钟后的 P95 延迟作为核心对比指标，结果如下：

这张表的信息量极大。首先，Premium SSD 的 P95 延迟高达 89.2ms，这在绝大多数在线交易系统中是不可接受的。深入看其子指标，WAL 写入 P95 延迟为 8.1ms，Raft 同步延迟为 15.7ms，两者相加已接近 24ms，剩下的 65ms 延迟，主要来自 YugabyteDB 自身的事务协调开销和网络传输。这说明老版 Premium SSD 的 IO 能力，已经成了整个 NewOrder 流水线的第一个瓶颈。升级到 Premium SSD v2 后，P95 延迟断崖式下跌到 32.5ms，降幅达 63%。其 WAL 和 Raft 延迟也同步大幅下降，证明 v2 的底层 NVMe 优化确实有效。此时，瓶颈开始向上转移，更多地体现在 YB 的 JVM GC 和 RPC 处理上。Ultra SSD 的数据看起来惊艳：P95 延迟仅 18.7ms，WAL 和 Raft 延迟都压到了 2ms 以内。但这 13.8ms 的提升（从 32.5ms 到 18.7ms），是建立在成本增加 3.5 倍的基础上的。更重要的是，我们观察到一个现象：当并发数从 128 提升到 256 时，Ultra SSD 的 P95 延迟只增加了 2.1ms，而 v2 增加了 5.8ms。这说明 Ultra SSD 在高并发下的“抗压性”确实更强，它的性能曲线更平缓。但对于大多数中小规模集群（< 200 并发），v2 的 32.5ms 已经完全能满足 SLA（通常要求 P95 < 50ms），再往上投入，性价比极低。我建议的决策树是：如果你的业务 P95 延迟目标是 < 30ms，且预算充足，Ultra SSD 是稳妥选择；如果你的目标是 < 50ms，那么 Premium SSD v2 是绝对的“甜点区”；如果你的业务对延迟不敏感（如后台报表），老版 Premium SSD 依然能胜任，只是要接受更高的运维复杂度。

4.2 Sysbench 读写性能对比：解剖微观 IO 效率

Sysbench 让我们得以剥离业务逻辑，直击存储的微观性能。以下是oltp_read_only（128 线程，20 表）和oltp_multi_insert（128 线程，20 表）在三款磁盘上的实测结果：

这个表格揭示了一个反直觉的真相：Ultra SSD 的 IOPS 效率（tps/IOPS）远低于 v2 和老版。这是因为 Ultra SSD 的设计哲学是“极致吞吐”，它用巨大的并行通道和智能调度算法，来处理海量的、大块的顺序 IO。但 Sysbench 的oltp_*工作负载，产生的是大量、小块、高度随机的 IO。Ultra SSD 的控制器在处理这种“碎片化”请求时，调度开销更大，导致单位 IOPS 能转化的事务数反而更低。而 Premium SSD v2 的控制器，恰恰是在这个“中等粒度、高并发随机 IO”场景下做了深度优化，所以它的效率最高。这也解释了为什么在 TPC-C 这种混合负载下，v2 的综合表现如此出色——它不是单项冠军，而是全能选手。另一个重要发现是：oltp_multi_insert的吞吐，与磁盘的“写入吞吐（MB/s）”相关性，远高于与“IOPS”的相关性。因为 INSERT 事务虽然由 10 次小写组成，但它们最终会批量刷入 WAL 和 SSTable，形成较大的顺序写流。我们用iostat观察到，v2 在oltp_multi_insert下的wMB/s（写入 MB/s）稳定在 180MB/s，而老版 Premium SSD 只有 65MB/s。这再次印证了 v2 在写入吞吐上的巨大优势。所以，对于写入密集型应用，不要只盯着 IOPS，更要关注磁盘的“最大吞吐量（MB/s）”参数。Ultra SSD 的 1000MB/s 吞吐，是为 PB 级数据湖准备的，对于 TB 级的 OLTP 数据库，v2 的 250MB/s 已经绰绰有余。

4.3 成本效益分析：每一分钱都花在刀刃上

性能数据再漂亮，最终都要落到钱上。我们以 1TB 磁盘、按月付费（Pay-as-you-go）的价格，计算了三款磁盘在不同配置下的“每千事务成本（Cost per 1000 TPS）”，这是最能反映真实性价比的指标。计算基于 Azure 官方定价（2025 年 3 月），并考虑了磁盘本身的费用、以及因性能差异导致的虚拟机规格节省（例如，v2 性能好，可能允许你用更小的 VM）。

这个表格彻底颠覆了“越贵越好”的认知。Ultra SSD 的总月费是 v2 的 1.8 倍，但其吞吐只比 v2 高 34%。结果就是，v2 的“每千事务成本”仅为 0.418 美元，而 Ultra SSD 是 0.565 美元，v2 的性价比高出 Ultra SSD 近 35%。更惊人的是，v2 的成本甚至比老版 Premium SSD 低了 58%！这是因为 v2 在提供更高性能的同时，其单位容量价格反而更低。这背后是 Azure 存储团队的技术迭代：v2 使用了更新的 NAND 闪存和更高效的控制器固件，使得在同等物理尺寸下，能提供更高的性能和更低的成本。所以，从财务视角看，Premium SSD v2 不是一个“折中选项”，而是一个“降本增效”的革命性选择。它让你用更少的钱，买到更好的性能，还能省下宝贵的运维精力。我强烈建议，除非你的业务有明确的、无法妥协的 < 20ms P95 延迟 SLA，否则不要轻易越过 v2 去选 Ultra SSD。把省下来的预算，投入到更强大的 CPU（比如换成 E20ds_v4）、更大的内存（256GB）、或者更专业的数据库监控工具上，往往能带来更显著的整体收益。

5. 实操指南与避坑心得：从选型到上线的完整 checklist

5.1 磁盘选型决策 checklist：5 个问题，1 分钟定乾坤

在 Azure 门户里点几下就能创建磁盘，但选错类型，后面要付出的代价是百倍的运维精力。我总结了一个极简的 5 问决策法，帮你 1 分钟内锁定最优解：

1. 你的核心业务 SLA 是什么？如果 P95 延迟要求 < 20ms，且写入吞吐 > 10000 tps，那么 Ultra SSD 是唯一选择。如果要求 < 50ms，Premium SSD v2 是黄金标准。如果 > 50ms，老版 Premium SSD 仍可一战。
2. 你的数据集大小和增长预期如何？如果当前数据 < 5TB，且年增长 < 2TB，v2 完全够用。如果数据已达 10TB+，且预计半年内破 20TB，那么 Ultra SSD 的超高吞吐（1000MB/s）和可配置 IOPS（最高 160000）能为你未来 2 年的扩展留足空间，避免频繁迁移。
3. 你的预算红线在哪里？把上面的成本效益表拿出来，算算“每千事务成本”。如果 Ultra SSD 带来的性能提升，无法转化为可量化的业务收入（比如，延迟从 32ms 降到 18ms，能让支付成功率提升 0.1%），那就果断选 v2。
4. 你的团队是否有能力调优 Ultra SSD？Ultra SSD 的威力，需要配合极致的 YugabyteDB 调优（如ysql_yb_enable_replication_delay=true,rocksdb_max_background_compactions=8,memstore_limit_mb=8192）和 Linux 内核参数（如vm.swappiness=1,net.core.somaxconn=65535）。如果你的团队没有这方面的资深专家，v2 的“开箱即用”稳定性，会为你省下无数个深夜排障的电话。
5. 你的应用是否真的“IO-bound”？这是最关键的一问。在升级磁盘前，务必用top,htop,iostat -x 1和 YB 的 Grafana Dashboard，确认当前瓶颈确实是磁盘（%util持续 > 90%,await> 20ms），而不是 CPU（%us> 80%）、内存（%wa高但free -h显示内存充足，说明是 swap）、或网络（netstat -s | grep "retrans"查重传率）。我见过太多客户，花了大价钱升级磁盘，结果发现瓶颈是 JVM 的-Xms和-Xmx设得太小，导致频繁 Full GC。

5.2 创建与配置的最佳实践：避开 Azure 控制台的“默认陷阱”

Azure 门户的默认配置，是为了通用性，而不是为了高性能。在创建磁盘时，必须手动修改以下关键参数：

• 启用“高级性能”（Advanced Performance）：在 Premium SSD v2 和 Ultra SSD 的创建向导中，有一个不起眼的开关叫 “Enable advanced performance”。必须打开它。这个选项会启用磁盘的“预配置”（Provisioned）模式，让 IOPS 和吞吐量在创建时就分配好，而不是像老版 Premium SSD 那样需要“热身”才能达到峰值。关闭它，你的 v2/Ultra SSD 就会退化成“伪 v2”。
• 禁用“缓存”（Caching）：在将磁盘附加到虚拟机时，Azure 会默认启用 “Read/Write” 缓存。对于 YugabyteDB 的 WAL 和数据盘，必须选择 “None”。因为 YB 自己的 RocksDB Block Cache 和 WAL Buffer 已经做了极致优化，OS 层的缓存只会增加一层不必要的拷贝和锁竞争，反而降低性能。我们实测过，开启 OS 缓存会让oltp_multi_insert的 P95 延迟增加 15%。
• 使用“托管磁盘加密”（Managed Disk Encryption）：虽然会带来微乎其微的 CPU 开销（< 1%），但这是生产环境的强制安全要求。Azure 的平台管理密钥（PMK）加密，性能