企业官网建设流程全解析

• 示例工程
• 数据库
• 教程
• 后端

导读

本文以 sql-server-samples 仓库中 UsingAzureRules.md 为核心，讲解如何让 SQL Assessment API 在评估 Azure 虚拟机（Azure VM）上的 SQL Server 实例时，启用仅适用于 Azure 环境的专属最佳实践规则。读完本文，你将掌握：前置 Azure PowerShell 与 Az.ResourceGraph 模块的准备方法、从登录到产出建议的完整评估命令链、评估结果各列字段的解读方式，以及 AzSqlVmSize 规则在 ruleset.json 中的真实定义与底层数据获取原理。

为什么 Azure VM 上的 SQL Server 需要专属规则

SQL Assessment API 是一个用于按最佳实践评估 SQL Server 配置的机制，随 API 交付的默认规则集由 SQL Server 团队维护，并随新版本持续增强（见 README.md）。默认规则集面向通用场景（本地实例、云上实例皆可），但对部署在 Azure VM 上的 SQL Server 而言，还有一类规则只有结合 Azure 环境信息才能生效——例如虚拟机规格是否适合承载 SQL Server 工作负载、Azure 数据磁盘的条带化与缓存配置是否合理等。

这些规则之所以“专属”，是因为它们依赖 Azure 订阅层面的资源元数据（虚拟机大小、磁盘布局等），而这类数据无法仅凭 SQL Server 实例本身获得。SQL Assessment cmdlet 的设计允许在评估 Azure VM 上的实例时，以“本地 SQL Server + Azure 环境规则”的双重视角同时工作：只要建立了活跃的 Azure 订阅连接，评估引擎就会自动加载并运行这些 Azure 专属规则。

前置条件：模块安装与 Azure 登录

在使用 Azure 专属规则之前，需要完成两项准备（对应原文档第 1、2 步）：

1. 安装两个 PowerShell 模块：

   • Azure PowerShell 模块（Az 系列模块，提供Connect-AzAccount、Set-AzContext等命令）；
   • Az.ResourceGraph 模块：用于向 Azure Resource Graph 发起查询，SQL Assessment 需要借助它获取 Azure 资源数据。

2. 先登录 Azure 再执行评估：在调用 SQL Assessment 对 Azure VM 上的 SQL Server 进行评估之前，必须先通过Connect-AzAccount建立 Azure 账户连接。

关于会话连接的一个重要注意事项

原文档特别强调：Azure 账户连接可以跨 PowerShell 会话持久化——即在一个会话中调用过Connect-AzAccount后，后续会话可以省略该命令。但在这种场景下，SQL Assessment cmdlet 需要显式导入 Az.ResourceGraph 模块，否则无法获取 Azure 资源图数据：

Import-Module Az.ResourceGraph

也就是说，持久化的是“登录状态”，而“模块加载”并不会随登录状态一起保留，每个新会话都必须手动执行Import-Module。

补充：SQL Assessment 的某些高级功能（如本文涉及的 Azure 环境类规则）依赖较新的 SqlServer PowerShell 模块版本。仓库中的 docs/README.md 提示，部分文档描述的功能仅在SqlServer 模块 22.0.30-preview 或更高版本中可用，安装时建议使用较新版本模块，例如Install-Module -Name SqlServer -AllowClobber -Force（见 QuickStart.md）。

分步执行 Azure VM 上的 SQL Server 评估

下面以原文档的完整流程为准，展示如何对一台 Azure VM 上的 SQL Server 实例发起评估。此流程中，活跃的 Azure 订阅连接使得AzSqlVmSize这类 Azure 专属规则得以启用。

第 1 步：建立 Azure 账户连接

Connect-AzAccount

该命令建立与 Azure 账户的连接，使后续评估能够通过 Azure Resource Graph 获取资源数据。

第 2 步（可选）：切换订阅上下文

Set-AzContext My-Pay-As-You-Go

当账户下存在多个订阅时，可用Set-AzContext指定要使用的订阅（示例中为名为My-Pay-As-You-Go的订阅）。这一步是可选步骤，不执行时使用当前默认上下文。

第 3 步（可选）：创建凭据对象

$cred = Get-Credential

Get-Credential会弹出窗口交互式收集用户名与密码，并生成凭据对象$cred，用于连接目标 SQL Server 实例。

第 4 步：选择要评估的 SQL Server 对象

$target = Get-SqlInstance -ServerInstance "Computer002\InstanceName" -Credential $cred

Get-SqlInstance获取指定的 SQL Server 实例对象。其中：

• -ServerInstance "Computer002\InstanceName"是目标计算机名与实例名的组合（注意这里展示的是命名实例写法，若为默认实例则直接写服务器名即可）；
• -Credential是可选参数，可以省略——省略时使用当前 Windows 身份或默认凭据连接。

说明：Get-SqlInstance、Invoke-SqlAssessment均来自 SqlServer PowerShell 模块，这也印证了前置条件中安装/更新 SqlServer 模块的必要性。

第 5 步：运行评估

Invoke-SqlAssessment $target

Invoke-SqlAssessment会为每个输入对象构建检查清单，逐项运行规则，并返回最佳实践建议列表。评估结束后，输出结果类似下面这样（来自原文档的示例输出）：

TargetPath : Server[@Name='ContosoAzureSQL'] Sev. Message Check ID Origin ---- ------- -------- ------ Medi Amount of single use plans in cache is high (100%). Consider PlansUseRatio Microsoft Ruleset 0.1.202 enabling the Optimize for ad hoc workloads setting on heavy OLTP ad-hoc workloads to conserve resources Low Use memory optimized virtual machine sizes for the best AzSqlVmSize Microsoft Ruleset 0.1.202 performance of SQL Server workloads

对同一实例的所有数据库进行评估

如果希望不仅评估实例级配置，还想评估该实例上所有数据库的配置，可以将数据库对象直接管道传递给评估命令（该写法来自 QuickStart.md 中针对本地实例的示例，同样适用于 Azure VM 场景）：

Get-SqlDatabase -ServerInstance "Computer002\InstanceName" | Invoke-SqlAssessment

解读评估结果：四列字段与严重级别

原文档对示例输出给出了明确的字段说明，整理如下：

在上面的示例中，PlansUseRatio是一条通用规则，它检测到“单次使用计划在缓存中占比过高（100%）”，建议在重 OLTP 即席工作负载上启用“针对即席工作负载进行优化”设置以节约资源；而AzSqlVmSize则是仅适用于部署在 Azure VM 上的 SQL Server的规则，它检查虚拟机的大小是否为内存优化型（memory-optimized）。

深挖 AzSqlVmSize 规则：ruleset.json 中的真实定义

AzSqlVmSize并非概念性描述，它在仓库的 ruleset.json 中有完整的规则定义，这正是理解该规则行为的最佳依据：

{ "id": "AzSqlVmSize", "itemType": "definition", "target": { "type": "Server", "platform": "Windows", "engineEdition": "SqlServer", "version": "[11.0,)", "machineType": "AzureVm" }, "tags": [ "DefaultRuleset", "SqlOnVm", "Azure", "Performance" ], "displayName": "VM size is not memory-optimized", "description": "Memory optimized VM sizes offer a high memory-to-CPU ratio that is great for relational database servers. The DSv2 11-15, Edsv4 series, the M-, and the Mv2- series offer the optimal memory-to-vCore ratio required for OLTP workloads. Both M series VMs offer the highest memory-to-vCore ratio required for mission critical workloads and is also ideal for data warehouse workloads.", "message": "Use memory optimized virtual machine sizes for the best performance of SQL Server workloads", "helpLink": "https://docs.microsoft.com/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices", "level": "Information", "condition": { "imatch": "@vmSize", "(^Standard_DS?1[1-5?_v2$)|(^Standard_E\\d+[asi]*(-\\d+[sad]+)?_v[3-4]$)|(^Standard_M\\d+[ltms]*(-\\d+[ms]+)?(_v21?)?$)|(^Standard_GS\\d+-\\d+$)" ] }, "probes": [ "AzVmProps" ] }

从该定义可以提炼出几个关键实现事实：

• 适用范围（target）：type为Server、platform为Windows、engineEdition为SqlServer、version为11.0,)（即 SQL Server 2012 及以上版本），并且machineType必须是AzureVm——这正是“仅对 Azure VM 上的 SQL Server 生效”的实现机制。

• 严重级别：level为Information，与文档所述结果列中的严重级别取值一致。

• 判定条件（condition）：使用imatch（不区分大小写的正则匹配）将探针返回的@vmSize变量与内存优化 VM 系列名模式比对。从正则可以看出，被认定为“内存优化”的 VM 系列包括：

  • Standard_DS11-15_v2/Standard_DS12-15_v2等 DSv2 系列（Standard_DS?1[1-5?_v2）；
  • Standard_E*_v3/Standard_E*_v4等 Edsv4/E 系列内存优化变体（Standard_E\d+[asi]*(-\d+[sad]+)?_v[3-4]）；
  • M 与 Mv2 系列（Standard_M\d+[ltms]*(-\d+[ms]+)?(_v21?)?）；
  • GS 系列（Standard_GS\d+-\d+）。

  这些正是规则描述中提到的“高内存-CPU 配比、适合关系型数据库服务器与 OLTP 工作负载”的系列——其中 M 系列还被描述为适合关键任务与数据仓库工作负载（该描述同样可见于可读规则清单 DefaultRuleset.csv 中AzSqlVmSize一行）。当 VM 大小不匹配这些模式时，规则即触发，输出“Use memory optimized virtual machine sizes for the best performance of SQL Server workloads”的建议。

• 数据来源（probes）：规则引用探针AzVmProps。在 ruleset.json 中，AzVmProps的实现类型为AzMetadata，目标同样限定为machineType: AzureVm，其implementation.query为 JSONPath 表达式$.compute，用于取出 VM 计算规格信息。

Azure 专属规则的数据获取原理：AzMetadata 与 AzGraph 探针

AzSqlVmSize 背后的数据链路，体现了 SQL Assessment 在 Azure 环境下的探针设计，这在仓库的探针参考文档中有明确说明：

• AzMetadata 探针（见 AzMetadataProbe.md，类型码AzMetadata）：返回可通过Azure 实例元数据服务（Azure Instance Metadata Service, IMDS）获取的数据。IMDS 以 JSON 对象形式返回数据，AzMetadata探针通过JSONPath从中提取所需字段——这正是AzVmProps使用$.compute获取 VM 规格（进而得到@vmSize）的原因。文档同时说明：当评估远程执行且 Azure Graph 可用时，IMDS 会被一条 Kusto 查询模拟替代。

• AzGraph 探针（见 AzGraphProbe.md，类型码AzGraph）：在Azure Resource Graph上运行 Kusto 查询，实现属性query为必填项，查询中可用@符号嵌入参数。示例：

  "implementation": { "query": "Resources | where id =~ @resId | project name" }

  这正是前置条件要求安装Az.ResourceGraph 模块并先执行Connect-AzAccount的原因——评估引擎需要借由该模块在 Azure Resource Graph 上执行 Kusto 查询，才能拿到 Azure 侧的资源元数据来支撑machineType: AzureVm类规则。若未登录或模块未加载，相关探针将无法取数，Azure 专属规则自然也就无法参与评估。

更多 Azure 环境专属规则与扩展方向

machineType: AzureVm机制不止服务于 AzSqlVmSize 一条规则，它是规则集里一类“按机器类型定向”的通用过滤能力：

• 在 ruleset.json 中可以看到以targetFilter.machineType: AzureVm声明的规则覆盖（override），例如NtfsBlockSizeNotFormatted（位于规则集后段），它针对 Azure VM 场景覆盖 NTFS 块大小检查的判定逻辑，将引导盘、临时盘等因素纳入考虑；
• 仓库的 release-notes.md 中列出的多条 Azure 相关检查也印证了这一点，例如Azure 数据磁盘条带化（Azure data disk striping）、Azure 磁盘缓存（Azure disk caching for data files / transaction logs）、数据文件位于 Azure 数据磁盘（Data files on Azure data disks）、tempdb 文件位于 Azure 临时盘（Tempdb files on Azure temp drive）、为 SQL Server 数据文件使用高级 SSD（Use premium SSDs for SQL Server data files）等——这些都属于依赖 Azure 资源元数据的专属规则。

如果你希望深入了解这些探针的更多细节（包括非 SQL 类探针如何从操作系统取数），可以继续阅读仓库内的 How-To 索引 下的 UsingNonSQLProbes.md，以及 Reference/Probes 目录 中的探针参考文档。

小结与建议

要让 SQL Assessment API 对 Azure VM 上的 SQL Server 执行“环境感知”的评估，关键链路是：安装 Azure PowerShell 与 Az.ResourceGraph 模块 → 先 Connect-AzAccount 登录并保持订阅连接 →（若跨会话则显式 Import-Module Az.ResourceGraph）→ Get-SqlInstance 获取实例 → Invoke-SqlAssessment 执行评估。评估输出中的Origin列会标明规则来源，Check ID列则对应规则 ID——你可以在 ruleset.json 中按 ID 检索任意规则的完整定义（target 范围、tags、level、condition 与 probes），也可以借助 DefaultRuleset.csv 快速浏览全部内置规则的可读描述。对已部署在非内存优化系列 VM 上的 SQL Server，AzSqlVmSize 规则给出的建议，可作为 VM 规格选型与性能优化的参考依据。

• 示例工程
• 数据库
• 教程
• 后端