手册

一个任务关键型 SQL 数据库需要 99.995% 的 SLA、区域冗余 HA 和读取横向扩展功能。

→使用启用区域冗余的业务关键型服务层级部署 Azure SQL Database。

原因: 业务关键型服务层级提供最高的 SLA，使用本地 SSD 实现低延迟，并包含免费的内置可读辅助副本。通用型服务层级具有较低的 SLA 且没有内置读取副本。

参考↗

一个数据库具有不可预测的间歇性使用模式，且有长时间的空闲期。成本优化至关重要。

→使用无服务器计算模型的通用型服务层级部署 Azure SQL Database。

原因: 无服务器计算模型根据需求自动扩展计算资源，并在不活动期间自动暂停，只收取存储费用。对于非连续性工作负载，这比预配计算模型更具成本效益。

参考↗

迁移依赖于 SQL Server Agent、跨数据库查询和 Service Broker 等功能的本地 SQL Server。

→迁移到 Azure SQL Managed Instance。

原因: Managed Instance 提供与本地 SQL Server 接近 100% 的兼容性，保留了 Azure SQL Database 中不可用的实例级功能。

参考↗

某个应用程序需要操作系统级别访问、文件系统访问（例如用于 Filestream）或 PaaS 产品不支持的功能（例如带有 EXTERNAL_ACCESS 的 CLR）。

→在 Azure 虚拟机 (IaaS) 上部署 SQL Server。

原因: IaaS 提供对操作系统和 SQL Server 实例的完全控制，以增加管理开销为代价，提供了与本地配置的最大兼容性。

数据库预计将增长到 4 TB 以上，最高可达 100 TB，并需要快速的存储扩展和快速恢复。

→使用超大规模 (Hyperscale) 服务层级部署 Azure SQL Database。

原因: 超大规模专为超大型数据库 (VLDB) 设计，提供高达 100 TB 的存储，可自动扩展。它采用独特的架构，通过页面服务器实现快速、与大小无关的恒定时间数据库恢复。

参考↗

一个 SaaS 应用程序托管了许多具有不同且不可预测使用模式的小型数据库。需要在提供共享资源的同时优化成本。

→将数据库分组到 Azure SQL Database 弹性池中。

原因: 当所有租户的使用情况不恒定时，弹性池允许多个数据库以固定价格共享一组资源 (eDTU 或 vCore)，这比单独预配数据库更具成本效益。

将 Azure SQL Managed Instance 部署到虚拟网络中。

→创建一个最小大小为 /27 (32 个地址) 的专用子网，并将其委托给 Microsoft.Sql/managedInstances。

原因: Managed Instance 需要一个专用且空的子网，该子网具有足够的 IP 地址供其内部组件和未来扩展使用。/27 是支持的最小大小。

以最小停机时间将大型任务关键型本地 SQL Server 数据库迁移到 Azure。

→在在线迁移模式下使用 Azure Database Migration Service (DMS)。

原因: DMS 在线迁移执行初始加载，然后使用持续数据同步（日志传送）使目标保持同步，从而实现非常短的切换窗口。

为在 Azure VM 上托管数据仓库工作负载且具有大量顺序读取的 SQL Server 配置存储。

→使用高级 SSD。为数据文件配置只读主机缓存，为日志文件配置无缓存。

原因: 只读缓存最适合数据仓库中常见的大量顺序读取。日志文件必须禁用缓存，以确保写入持久性并防止数据丢失。

安全策略要求所有数据库连接都必须加密并验证服务器证书。

→将服务器上的最小 TLS 版本设置为 1.2。在客户端连接字符串中，使用 `Encrypt=Strict`。

原因: 在服务器上设置最小 TLS 版本可防止不安全的协议协商。`Encrypt=Strict` (TDS 8.0+) 强制加密和完整证书验证，防止中间人攻击。

特定列（例如 SSN）中的敏感数据必须加密，但应用程序需要对加密数据执行相等查找和联接。

→对可搜索列使用带有确定性加密的 Always Encrypted。

原因: 确定性加密为给定的明文值生成相同的密文，从而允许相等比较。随机化加密提供更强的保护，但不允许这些操作。

需要静态数据加密，但组织必须完全控制加密密钥。

→启用透明数据加密 (TDE) 并使用存储在 Azure Key Vault 中的客户管理密钥 (BYOK)。

原因: 此配置允许组织在其自己的 Key Vault 中管理密钥生命周期（轮换、撤销），从而提供对密钥所有权的控制并满足合规性要求。

Azure SQL Database 必须只能从特定的 Azure Virtual Network 访问，并且完全阻止公共互联网访问。

→为 SQL Server 配置 Private Endpoint，并将“拒绝公共网络访问”设置为“是” (Yes)。

原因: Private Endpoint 为 SQL 数据库提供了 VNet 内的私有 IP。禁用公共访问确保它是连接的唯一方式，提供完全的网络隔离。

多租户应用程序必须确保用户只能在共享表中看到自己的数据。

→通过创建安全谓词（内联表值函数）和将其应用于表的安全策略来实施行级安全性 (RLS)。

原因: RLS 根据用户上下文（例如 USER_NAME() 或 SESSION_CONTEXT）透明地筛选行，在数据库引擎级别强制执行数据隔离，而无需更改应用程序。

数据库管理员需要管理数据库，但应该无法查看某些列中的敏感数据。

→在敏感列上实施动态数据屏蔽 (DDM)。不要授予 DBA UNMASK 权限。

原因: DDM 为非特权用户混淆查询结果中的数据，而无需更改存储的数据。这允许 DBA 履行职责，同时防止他们看到实际的敏感信息。

安全策略要求禁用 SQL 身份验证，以强制执行 Azure SQL DB 或 Managed Instance 的集中式身份管理和 MFA。

→为服务器设置 Azure AD 管理员并启用“仅限 Azure AD 身份验证”属性。

原因: 此设置完全禁用 SQL 身份验证端点，强制所有连接使用 Azure AD。这是强制执行现代身份验证策略的关键步骤。

需要检测异常数据库活动并接收警报，包括潜在的 SQL 注入、异常访问模式和暴力攻击。

→启用 Microsoft Defender for SQL (以前称为高级威胁防护)。

原因: Defender for SQL 分析数据库日志中的可疑活动并生成安全警报，在基本访问控制之外提供关键的威胁检测层。

Azure SQL Database 的审计日志必须保留数年，并且可搜索以用于合规性和安全调查。

→配置 Azure SQL 审计，将日志发送到已配置所需数据保留的 Log Analytics 工作区。

原因: Log Analytics 提供长期保留和强大的基于 KQL 的查询功能，使其在可搜索的长期审计数据方面优于 Blob Storage。

为 DevOps 团队提供临时、有时限且经过批准的数据库访问权限，以进行故障排除。

→使用 Azure AD Privileged Identity Management (PIM) 来管理具有数据库访问权限的 Azure AD 组的资格。

原因: PIM 提供可审计、需要理由且自动过期的即时 (JIT) 访问权限，遵循最小特权原则。

系统需要可验证、防篡改的所有数据修改历史记录，以满足严格的法规遵从性要求。

→使用 Azure SQL Database ledger 功能。

原因: Ledger 表使用区块链概念以加密方式链接数据更改，创建不可变的历史记录，可以独立验证。这比时间表更强大，时间表不具备防篡改性。

数据库正在经历性能下降。需要识别消耗资源最多的查询、跟踪计划更改并查找性能回归。

→启用并利用 Query Store。

原因: Query Store 是查询性能的内置“飞行数据记录器”。它自动捕获查询历史记录、计划和等待统计信息，是随时间诊断性能问题的主要工具。

参考↗

由于参数嗅探问题，某个查询有时运行良好，有时运行不佳，因为执行计划针对非代表性参数值进行了优化。

→使用 Query Store 识别不同的计划并强制执行始终良好的执行计划。

原因: Query Store 中的计划强制提供了一种快速有效的方法来稳定有问题的查询的性能，而无需更改代码。它用一个已知良好的计划覆盖优化器的选择。

通过利用行存储上的批处理模式、内存授予反馈和表变量延迟编译等功能，在不更改代码的情况下提高查询性能。

→将数据库兼容级别设置为 150（适用于 SQL 2019 功能）或更高。

原因: 智能查询处理 (IQP) 功能集由数据库兼容级别启用。级别 150+ 激活查询处理器中广泛的“无需代码更改”性能增强功能。

当关键性能指标（如 CPU 百分比或死锁）超过定义的阈值时，运营团队需要收到通知。

→使用 Azure Monitor 创建指标警报（针对 CPU）和日志警报（针对死锁），它们会触发一个操作组。

原因: Azure Monitor 是用于监视和警报 Azure 资源的集中式平台。操作组提供灵活的通知渠道（电子邮件、短信、webhook 等）。

通过识别和删除任何读取查询未使用的索引来提高写入性能。

→查询 `sys.dm_db_index_usage_stats` DMV。

原因: 此 DMV 跟踪索引使用情况（查找、扫描、搜索）与更新。更新次数多但使用次数为零或非常低的索引是删除的首选，可减少维护开销。

需要捕获有关间歇性阻塞问题的详细信息，包括阻塞链中涉及的语句和会话。

→配置捕获 `blocked_process_report` 事件的 Extended Events 会话。

原因: 当超出 `blocked process threshold` 时，此事件提供阻塞链的详细 XML 报告，提供 DMV 中不可用的深度诊断信息。

数据库需要其索引策略自动适应不断变化的工作负载模式，无需手动干预。

→在 Azure SQL Database 自动优化中启用 CREATE_INDEX 选项。

原因: 此功能允许 Azure 分析工作负载，识别具有高影响的缺失索引，创建它们并验证其性能优势，从而自动化关键 DBA 任务。

将读密集型报告工作负载从业务关键型或高级层中的主 OLTP 数据库卸载。

→修改应用程序的只读连接字符串以包含 `ApplicationIntent=ReadOnly`。

原因: 这些层包含一个免费的内置可读辅助副本。连接字符串中的 `ApplicationIntent` 属性会自动将只读连接路由到此副本，隔离读取工作负载。

数据仓库中的一个大型事实表经常用于聚合查询 (SUM, COUNT, AVG)，但执行缓慢。

→在事实表上创建聚集列存储索引。

原因: 列存储索引以列式格式存储数据，提供非常高的数据压缩并启用批处理模式执行，这极大地加速了聚合和扫描密集型分析查询。

数据库在读取查询（报告）和写入查询（事务）之间遇到严重的阻塞争用。

→在数据库上启用读提交快照隔离 (RCSI)。

原因: RCSI 使用行版本控制，允许读取器查看数据的最后提交版本，而无需获取共享锁，从而消除写入器造成的阻塞。写入器不会阻塞读取器。

使用无服务器数据库的应用程序在一段时间不活动后，首次连接时速度较慢。

→缩短自动暂停延迟或将最小 vCore 值配置为大于零。

原因: 延迟是由于数据库从暂停状态恢复（冷启动）引起的。设置最小 vCore 值可防止数据库完全暂停，从而消除恢复延迟，但会产生成本。

为自动化、版本控制和可重复的数据库架构部署实施 CI/CD 管道。

→使用 SQL 数据库项目（例如在 Visual Studio 中）生成 DACPAC 文件。使用 Azure DevOps 管道部署 DACPAC。

原因: 这是 SQL 架构的标准基础设施即代码 (IaC) 模式。DACPAC 是架构的声明性模型，部署工具负责生成差异脚本，确保一致性。

Azure SQL Database 需要根据计划或指标阈值（例如高 CPU）自动扩展或缩减。

→使用由计划或 Azure Monitor 警报触发的 Azure Automation runbook (PowerShell)。

原因: Azure SQL Database（预配层）没有内置的自动缩放功能。Azure Automation 是使用脚本和计划编排此类操作任务的标准工具。

需要对数百个 Azure SQL 数据库执行维护脚本（例如索引重建）。

→使用弹性作业 (Elastic Jobs)。

原因: 弹性作业是一种 PaaS 服务，专门用于在目标数据库组上运行 T-SQL 作业，集中管理凭据、计划和日志记录。

确保订阅中所有新创建的 Azure SQL Server 默认启用特定功能，例如 TDE 或审计。

→创建具有 `DeployIfNotExists` 或 `Modify` 效果的 Azure Policy。

原因: Azure Policy 提供大规模治理。`DeployIfNotExists` 效果将在资源创建期间自动配置缺失的设置，无需手动干预即可强制执行合规性。

在 Azure SQL Managed Instance 上计划定期 T-SQL 脚本或维护任务。

→使用内置的 SQL Server Agent。

原因: Managed Instance 包含完整的 SQL Server Agent，提供与本地 SQL Server 相同且熟悉的作业计划功能，而无需外部自动化服务。

控制 Azure 何时对 Azure SQL Database 或 Managed Instance 执行计划维护，以最大程度地减少对业务运营的影响。

→为资源配置维护时段 (Maintenance Window)。

原因: 此功能允许您选择预定义的时间段（例如周末）供 Azure 应用更新，从而使您能够预测影响服务的维护。

应用程序需要自动故障转移到辅助区域以进行灾难恢复，而无需更改连接字符串。

→在主数据库/实例和辅助数据库/实例之间配置自动故障转移组 (Auto-Failover Group)。

原因: 故障转移组提供读写和只读侦听器端点。这些端点在故障转移后自动将流量重定向到当前主/辅助服务器，使过程对应用程序透明。

数据库备份必须保留多年（例如 7-10 年）以满足法律或法规遵从性要求。

→配置长期备份保留 (LTR) 策略。

原因: 标准时间点恢复 (PITR) 备份最多保留 35 天。LTR 将完整备份存储在单独的 Azure Blob Storage 中长达 10 年，专门用于合规性需求。

数据库必须在单个 Azure 区域内的某个数据中心（可用区）发生故障时保持可用。

→为业务关键型或高级层数据库启用区域冗余配置。

原因: 区域冗余在同一区域内的不同物理数据中心部署同步辅助副本，为区域级中断提供 RPO 接近零的自动故障转移。

Azure SQL Managed Instance 需要在配对的 Azure 区域中提供具有自动故障转移功能的灾难恢复解决方案。

→为 Managed Instance 配置自动故障转移组 (Auto-Failover Group)。

原因: 这是 Managed Instance 的规范 DR 模式，提供异步复制、用于透明应用程序故障转移的侦听器端点和自动化故障转移选项。

需要能够将数据库恢复到上个月的任何特定秒数。

→将短期备份保留 (PITR) 期限配置为 30-35 天。

原因: Azure SQL 自动执行完整备份、差异备份和频繁的事务日志备份。PITR 保留设置（1-35 天）决定了这些备份的保留时间，定义了时间点恢复的窗口。

为 Azure VM 上的 SQL Server Always On 可用性组配置 Windows Server 故障转移群集。

→使用云见证 (Cloud Witness) 作为仲裁见证。

原因: 云见证使用 Azure Blob Storage，是 Azure 中群集的推荐、最具弹性的选项。它避免了文件共享见证所需的第三个 VM 或复杂的共享磁盘配置。

在需要共享存储的 Azure VM 上实施 SQL Server 故障转移群集实例 (FCI)。

→使用 Azure 共享磁盘（将托管磁盘附加到多个 VM）。

原因: Azure 共享磁盘是 Azure 的原生解决方案，用于提供可由多个 VM 访问的块存储，这是传统 FCI 的先决条件。

需要在不影响生产主数据库的情况下测试故障转移组的灾难恢复过程。

→在低影响维护时段内启动计划的（手动）故障转移，验证应用程序连接，然后故障回复。

原因: 计划的故障转移确保不会丢失数据，并且是验证整个 DR 过程（包括 DNS 传播和应用程序重新连接）最彻底的方法。这是一个短暂、受控的生产事件。