你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 架构良好的框架评审 - Azure SQL 数据库
Azure SQL 数据库是一个完全托管的平台即服务 (PaaS) 数据库引擎，可在无需用户参与的情况下处理大多数数据库管理功能。 管理功能包括升级、修补程序、备份和监视。
单一数据库资源类型使用自己的一组资源在Azure SQL 数据库中创建一个数据库，并通过逻辑服务器进行管理。 可以在基于 DTU 的 购买模型 或 基于 vCore 的购买模型之间进行选择。 可以使用弹性池在单个资源池中创建多个数据库。
以下部分包括特定于Azure SQL 数据库安全性的设计清单和建议的设计选项。 本指南基于建筑卓越五大支柱：
- 可靠性
- 安全性
- 成本优化
- 卓越运营
- 性能效率
先决条件
了解架构良好的框架支柱有助于生成高质量、稳定且高效的云体系结构。 请查看 Azure 架构良好的框架概述页 ，查看体系结构卓越五大支柱。
Azure SQL 数据库和可靠性
Azure SQL 数据库是一个完全托管的平台即服务 (PaaS) 数据库引擎，可在无需用户参与的情况下处理大多数数据库管理功能。 管理功能包括：
- 升级
- 修补程序
- 备份
- 监视
使用此服务，你可以为 Azure 应用程序和工作负载创建高度可用和高性能的数据存储层。 Azure SQL 数据库始终在最新稳定版 SQL Server 数据库引擎和具有 99.99% 可用性的已修补操作系统中运行。
要详细了解 Azure SQL 数据库如何提高可靠性并让你的业务在中断期间继续运作，请参阅可用性功能。
以下部分包括设计注意事项、配置清单，以及特定于 Azure SQL 数据库的建议配置选项和可靠性。
设计注意事项
Azure SQL 数据库包括以下设计注意事项：
配置了异地复制功能的 Azure SQL 数据库业务关键服务层级具有保证的恢复时间目标 (RTO)：针对
100%的部署时间，恢复时间为30秒。使用分片，跨多个结构相同的数据库分布数据和流程。 分片提供针对成本和弹性的传统纵向扩展方法的替代方案。 考虑使用分片将数据库横向分区。 分片可提供故障隔离。 有关详细信息，请参阅使用 Azure SQL 数据库进行横向扩展。
未为区域冗余部署配置的 Azure SQL 数据库业务关键服务层级或高级服务层级、常规用途服务层级、标准服务层级或基本服务层级，或具有两个或多个副本的超大规模服务层级具有可用性保证。 要详细了解可用性保证，请参阅适用于 Azure SQL 数据库的 SLA。
向任何 Azure 区域提供内置的区域高可用性和全包式异地复制。 该数据库包含支持自驱动功能的智能，例如：
- 性能调优
- 威胁监视
- 漏洞评估
- 完全自动修补和更新代码库
定义应用程序性能的 SLA，并通过警报对其进行监视。 应用程序性能无意中降低到可接受级别时，进行快速检测，这对于维护高复原能力非常重要。 使用之前定义的监视解决方案来设置关键查询性能指标的警报，以便在性能违反服务级别协议时采取行动。 有关详细信息，请转到 监视数据库 和 警报工具 。
发生服务中断后使用异地还原进行恢复。 可以从最近的异地复制备份还原任何SQL 数据库服务器上的数据库或任何 Azure 区域中任何托管实例上的实例数据库。 异地还原使用异地复制的备份作为源。 即使在因中断而无法访问数据库或数据中心的情况下，也可以请求异地还原。 异地还原可从异地冗余的备份还原数据库。 有关详细信息，请参阅使用自动数据库备份恢复 Azure SQL 数据库。
使用配置了异地复制功能的业务关键层，该层具有保证的恢复点目标 (RPO)：针对
100%的部署时间，恢复时间为5秒。使用 Azure SQL 数据库中内置的 PaaS 功能，你可以专注于对业务至关重要的特定于域的数据库管理和优化活动。
发生人为错误后使用时间点还原进行恢复。 时间点还原可将数据库返回到较早的时间点，以从无意中所做的更改中恢复数据。 有关详细信息，请阅读《时间点还原 (PITR)》文档。
业务关键服务层级或高级服务层级配置为具有可用性保证的区域冗余部署。 要详细了解可用性保证，请参阅适用于 Azure SQL 数据库的 SLA。
清单
配置 Azure SQL 数据库时是否考虑了可靠性？
- 使用活动异地复制在其他区域中创建可读辅助。
- 使用可以包含一个或多个数据库（通常由同一应用程序使用）的自动故障转移组。
- 使用区域冗余数据库。
- 以准实时的方式监视 Azure SQL 数据库，以检测可靠性事件。
- 实现重试逻辑。
- 备份密钥。
配置建议
浏览以下建议表以优化针对可靠性的 Azure SQL 数据库配置：
| 建议 | 说明 |
|---|---|
| 使用活动异地复制在其他区域中创建可读辅助。 | 如果主数据库发生故障，请执行到辅助数据库的手动故障转移。 在故障转移之前，辅助数据库将保持只读状态。 使用活动异地复制，可以创建可读副本，并且可在发生数据中心中断或应用程序升级期间手动故障转移到任何副本。 在相同或不同的区域中最多支持四个辅助数据库，并且辅助数据库也可以用于只读访问查询。 故障转移必须由应用程序或用户手动启动。 故障转移后，新的主数据库具有不同的连接终结点。 |
| 使用可以包含一个或多个数据库（通常由同一应用程序使用）的自动故障转移组。 | 你可以使用可读辅助数据库卸载只读查询工作负载。 由于自动故障转移组涉及多个数据库，这些数据库必须在主服务器上进行配置。 自动故障转移组支持将组中的所有数据库复制到另一个区域中唯一的辅助服务器或实例。 详细了解自动故障转移组和灾难恢复设计。 |
| 使用区域冗余数据库。 | 默认情况下，将在同一数据中心创建高级可用性模型的节点群集。 引入 Azure 可用性区域后，SQL 数据库可以将业务关键数据库的不同副本放置到同一区域的不同可用性区域中。 若要消除单一故障点，还要将控件环跨区域地复制为三个网关环 (GW)。 到特定网关环的路由受 Azure 流量管理器 (ATM) 控制。 高级或业务关键服务层级中的区域冗余配置不会创建额外的数据库冗余，因此无需额外付费即可启用。 详细了解区域冗余数据库。 |
| 以准实时的方式监视 Azure SQL 数据库，以检测可靠性事件。 | 使用其中一个可用的解决方案来监视 SQL DB，尽早检测到潜在的可靠性事件，并提高数据库的可靠性。 选择准实时监视解决方案以对事件做出快速响应。 有关详细信息，请参阅 Azure SQL 分析。 |
| 实现重试逻辑。 | 尽管 Azure SQL 数据库在发生传递性基础结构故障时可复原，但这些故障可能会影响连接性。 使用 SQL 数据库时，如果发生暂时性错误，请确保你的代码可以重试该调用。 有关详细信息，请参阅如何实现重试逻辑。 |
| 备份密钥。 | 如果未在 Azure Key Vault 中使用加密密钥来保护数据，请备份密钥。 |
Azure SQL 数据库和安全性
SQL 数据库提供一系列内置安全性和符合性功能，帮助应用程序满足各种安全性和符合性要求。
设计清单
你是否设计了工作负荷并配置了Azure SQL 数据库，但考虑到安全性？
- 了解 逻辑服务器 以及如何在适当情况下管理多个数据库的登录名。
- 使用 Azure SQL 启用Microsoft Entra 身份验证。 Microsoft Entra 身份验证可实现简化的权限管理和集中式标识管理。
- Azure SQL 逻辑服务器应预配 Microsoft Entra 管理员。
- 验证 Azure 订阅中服务管理员和共同管理员的联系信息电子邮件地址是否在企业内部联系到正确的参与方。 你不想错过或忽略来自 Azure 的重要安全通知！
- 查看Azure SQL 数据库连接体系结构。
Redirect根据需要选择或Proxy连接策略。 - 查看Azure SQL 数据库防火墙规则。
- 使用 虚拟网络规则 控制来自虚拟网络中特定子网的通信。
- 如果使用Azure 防火墙，请使用 SQL FQDN 配置Azure 防火墙应用程序规则。
建议
| 建议 | 好处 |
|---|---|
| 查看 最低 TLS 版本。 | 确定是否具有需要较旧 TLS 或未加密连接的旧应用程序。 在设置为 TLS 的某个版本后，不能还原为默认值。 通过Azure 门户查看和配置SQL 数据库连接的最低 TLS 版本。 否则，请将最新的 TLS 版本设置为最小值。 |
| 账本 | 请考虑基于 账本 设计数据库表，以提供对所有数据更改的审核、篡改证据和信任。 |
| Always Encrypted | 考虑设计基于 Always Encrypted 的应用程序访问，通过委派对加密密钥的数据访问来保护应用程序中的敏感数据。 |
| 专用终结点和专用链接 | 专用终结点连接通过启用与Azure SQL 数据库的专用连接来强制实施安全通信。 默认情况下，可以使用专用终结点来保护连接并拒绝公共网络访问。 Azure SQL 数据库的Azure 专用链接是建议用于Azure SQL 数据库的专用终结点类型。 |
| 自动漏洞评估 | 监视漏洞评估扫描结果和建议，了解如何修正数据库漏洞。 |
| 高级威胁防护 | 检测异常活动，指示使用高级威胁防护来访问或利用具有高级威胁防护的数据库进行Azure SQL 数据库的异常和潜在有害尝试。 高级威胁防护将其警报与 Microsoft Defender for Cloud 集成。 |
| 审核 | 使用审核Azure SQL 数据库跟踪数据库事件。 |
| 托管标识 | 请考虑配置用户分配的托管标识（UMI）。 Azure 资源的 托管标识无需在代码中管理凭据。 |
| 仅限 Microsoft Entra 身份验证 | 请考虑禁用基于 SQL 的身份验证，仅 允许Microsoft Entra 身份验证。 |
策略定义
查看 Azure 安全基线，了解Azure SQL 数据库和 Azure Policy 内置定义。
与 Azure SQL 相关的所有内置策略定义都列在内置策略中。
查看教程：保护Azure SQL 数据库中的数据库。
Azure SQL 数据库和成本优化
Azure SQL 数据库是一个完全托管的平台即服务 (PaaS) 数据库引擎，可在无需用户参与的情况下处理大多数数据库管理功能。 管理功能包括：
- 升级
- 修补程序
- 备份
- 监视
使用此服务，你可以为 Azure 应用程序和工作负载创建高度可用和高性能的数据存储层。 SQL 数据库包括内置智能，通过自动性能监视和优化来帮助你大幅降低运行和管理数据库的成本。
有关 Azure SQL 数据库如何提供节省成本功能的详细信息，请参阅计划和管理 Azure SQL 数据库成本。
以下部分包括配置清单以及特定于 Azure SQL 数据库和成本优化的建议配置选项。
清单
是否出于成本优化考虑而配置了 Azure SQL 数据库？
- 优化查询。
- 评估资源使用情况。
- 微调备份存储消耗。
- 评估无服务器Azure SQL 数据库。
- 请考虑为Azure SQL 数据库预留容量。
- 请考虑 弹性池来管理和缩放多个数据库。
配置建议
浏览以下建议表以优化针对成本节省的 Azure SQL 数据库配置：
| 建议 | 说明 |
|---|---|
| 优化查询。 | 使用查询性能见解和性能建议优化查询、表和数据库，以帮助减少资源消耗，并达到适当的配置。 |
| 评估资源使用情况。 | 评估所有数据库的资源使用情况，并确定它们是否已正确调整大小和预配。 对于非生产数据库，请考虑根据需要缩减资源。 例如，在运行负载测试或用户验收测试时，可以按需缩放数据库的 DTU 或 vCore。 |
| 微调备份存储消耗量 | 对于 Azure SQL 数据库中的 vCore 数据库，每种类型的备份（完整备份、差异备份和日志备份）所使用的存储量采用单独的指标在数据库监视窗格上进行报告。 只要备份存储消耗量不超过数据库的最大数据大小，就不会对备份收费。 额外的备份存储消耗量取决于各个数据库的工作负荷和最大大小。 有关详细信息，请参阅 备份存储消耗。 |
| 评估 Azure SQL 数据库无服务器。 | 请考虑在预配计算层上使用Azure SQL 数据库无服务器。 无服务器是单一数据库的计算层，可根据工作负载需求和帐单自动根据每秒使用的计算量来缩放计算。 无服务器计算层还将在仅对存储计费的非活动期间自动暂停数据库。 当活动返回时，它将自动恢复数据库。 Azure SQL 数据库无服务器并不适用于所有方案。 如果你有一个具有不可预知或突发使用模式的数据库，这些模式与低或空闲使用期交织在一起，则无服务器是一种有助于优化性价比的解决方案。 |
| 考虑Azure SQL 数据库的预留容量。 | 可以使用预留折扣来降低与 Azure SQL 数据库相关联的计算成本。 确定区域中 Azure SQL 数据库的总计算能力和性能层后，可以使用此信息预留容量。 可预留一到三年。 有关详细信息，请参阅通过预留容量节省资源成本。 |
| 弹性池有助于在 Azure SQL 数据库中管理和缩放多个数据库 | Azure SQL 数据库弹性池是一种简单且经济高效的解决方案，用于管理和缩放具有不断变化且不可预测的使用需求的多个数据库。 同一弹性池中的所有数据库位于单个服务器上，并以固定价格共享固定数量的资源。 有关详细信息，请参阅 弹性池来管理和缩放多个数据库。 |
有关详细信息，请参阅Azure SQL 数据库规划和管理成本。
Azure SQL 数据库和卓越运营
Azure SQL 数据库是一个完全托管的平台即服务 (PaaS) 数据库引擎，可在无需用户参与的情况下处理大多数数据库管理功能。 管理功能包括：
- 升级
- 修补程序
- 备份
- 监视
使用此服务，你可以为 Azure 应用程序和工作负载创建高度可用和高性能的数据存储层。 Azure SQL 数据库提供基于人工智能的高级监视和优化功能，以帮助排查数据库和解决方案的性能问题并实现其最高性能。
有关 Azure SQL 数据库如何促进卓越运营以及如何使业务在中断期间继续运营的详细信息，请参阅 Azure SQL 数据库中的监视和性能优化。
以下各部分包含特定于 Azure SQL 数据库和卓越运营的设计注意事项、配置清单和建议配置选项。
设计注意事项
Azure SQL 数据库包括以下设计注意事项：
配置了异地复制功能的 Azure SQL 数据库业务关键服务层级具有保证的恢复时间目标 (RTO)：针对
100%的部署时间，恢复时间为30秒。使用分片，跨多个结构相同的数据库分布数据和流程。 分片提供针对成本和弹性的传统纵向扩展方法的替代方案。 考虑使用分片将数据库横向分区。 分片可提供故障隔离。 有关详细信息，请参阅使用 Azure SQL 数据库进行横向扩展。
未为区域冗余部署配置的 Azure SQL 数据库业务关键服务层级或高级服务层级、常规用途服务层级、标准服务层级或基本服务层级，或具有两个或多个副本的超大规模服务层级具有可用性保证。 有关详细信息，请参阅 Azure SQL 数据库服务级别协议。
向任何 Azure 区域提供内置的区域高可用性和全包式异地复制。 该数据库包含支持自驱动功能的智能，例如：
- 性能调优
- 威胁监视
- 漏洞评估
- 完全自动修补和更新代码库
定义应用程序性能的 SLA，并通过警报对其进行监视。 应用程序性能无意中降低到可接受级别时，进行快速检测，这对于维护高复原能力非常重要。 使用之前定义的监视解决方案来设置关键查询性能指标的警报，以便在性能违反服务级别协议时采取行动。 有关详细信息，请参阅监视数据库。
发生服务中断后使用异地还原进行恢复。 可以从最近的异地复制备份还原任何SQL 数据库服务器上的数据库或任何 Azure 区域中任何托管实例上的实例数据库。 异地还原使用异地复制的备份作为源。 即使在因中断而无法访问数据库或数据中心的情况下，也可以请求异地还原。 异地还原可从异地冗余的备份还原数据库。 有关详细信息，请参阅使用自动数据库备份恢复 Azure SQL 数据库。
使用配置了异地复制功能的业务关键层，该层具有保证的恢复点目标 (RPO)：针对
100%的部署时间，恢复时间为5秒。使用 Azure SQL 数据库中内置的 PaaS 功能，你可以专注于对业务至关重要的特定于域的数据库管理和优化活动。
发生人为错误后使用时间点还原进行恢复。 时间点还原可将数据库返回到较早的时间点，以从无意中所做的更改中恢复数据。 有关详细信息，请阅读《时间点还原 (PITR)》文档。
业务关键层或高级层配置为区域冗余部署。 要详细了解可用性保证，请参阅适用于 Azure SQL 数据库的 SLA。
清单
你是否出于卓越运营考虑而配置了 Azure SQL 数据库？
- 使用活动异地复制在其他区域中创建可读辅助。
- 使用可以包含一个或多个数据库（通常由同一应用程序使用）的自动故障转移组。
- 使用区域冗余数据库。
- 以准实时的方式监视 Azure SQL 数据库，以检测可靠性事件。
- 实现重试逻辑。
- 备份密钥。
配置建议
浏览以下建议表以优化针对卓越运营的 Azure SQL 数据库配置：
| 建议 | 说明 |
|---|---|
| 使用活动异地复制在其他区域中创建可读辅助。 | 如果主数据库发生故障，请执行到辅助数据库的手动故障转移。 在故障转移之前，辅助数据库将保持只读状态。 使用活动异地复制，可以创建可读副本，并且可在发生数据中心中断或应用程序升级期间手动故障转移到任何副本。 在相同或不同的区域中最多支持四个辅助数据库，并且辅助数据库也可以用于只读访问查询。 故障转移必须由应用程序或用户手动启动。 故障转移后，新的主数据库具有不同的连接终结点。 |
| 使用可以包含一个或多个数据库（通常由同一应用程序使用）的自动故障转移组。 | 你可以使用可读辅助数据库卸载只读查询工作负载。 由于自动故障转移组涉及多个数据库，这些数据库必须在主服务器上进行配置。 自动故障转移组支持将组中的所有数据库复制到另一个区域中唯一的辅助服务器或实例。 详细了解自动故障转移组和灾难恢复设计。 |
| 使用区域冗余数据库。 | 默认情况下，将在同一数据中心创建高级可用性模型的节点群集。 引入 Azure 可用性区域后，SQL 数据库可以将业务关键数据库的不同副本放置到同一区域的不同可用性区域中。 若要消除单一故障点，还要将控件环跨区域地复制为三个网关环 (GW)。 到特定网关环的路由受 Azure 流量管理器 (ATM) 控制。 高级或业务关键服务层级中的区域冗余配置不会创建额外的数据库冗余，因此无需额外付费即可启用。 详细了解区域冗余数据库。 |
| 以准实时的方式监视 Azure SQL 数据库，以检测可靠性事件。 | 使用其中一个可用的解决方案来监视 SQL DB，尽早检测到潜在的可靠性事件，并提高数据库的可靠性。 选择准实时监视解决方案以对事件做出快速响应。 有关详细信息，请参阅 Azure SQL 分析。 |
| 实现重试逻辑。 | 尽管 Azure SQL 数据库在发生传递性基础结构故障时可复原，但这些故障可能会影响连接性。 使用 SQL 数据库时，如果发生暂时性错误，请确保你的代码可以重试该调用。 有关详细信息，请参阅 SqlClient 简介中如何实现重试逻辑和可配置重试逻辑。 |
| 备份密钥。 | 如果未在 Azure Key Vault 中使用加密密钥来保护数据，请备份密钥。 |
Azure SQL 数据库和性能效率
Azure SQL 数据库是一个完全托管的平台即服务 (PaaS) 数据库引擎，可在无需用户参与的情况下处理大多数数据库管理功能。 管理功能包括：
- 升级
- 修补程序
- 备份
- 监视
以下部分包括特定于Azure SQL 数据库性能效率的设计清单和建议的设计选项。
设计清单
你是否设计了工作负荷并配置了Azure SQL 数据库，并考虑到了性能效率？
- 查看资源限制。 对于单一数据库的每个定价层的资源限制（也称为服务目标），请参阅基于 DTU 的单一数据库资源限制或基于 vCore 的单一数据库资源限制。 有关弹性池资源限制，请参阅基于 DTU 的弹性池资源限制或基于 vCore 的弹性池资源限制。
- 为工作负荷、vCore 或 DTU 选择正确的部署模型。 比较基于 vCore 和 DTU 的购买模型。
- Microsoft建议最新的 vCore 数据库标准系列或高级系列硬件。 旧版 Gen4 硬件已停用。
- 使用弹性池时，请熟悉 资源治理。
- 查看默认的最大并行度（MAXDOP），并根据迁移的或预期的工作负荷根据需要进行配置。
- 请考虑使用 关键数据库的只读副本 来卸载只读查询工作负荷。
- 查看 SQL Server 性能中心数据库引擎和Azure SQL 数据库。
- 连接到Azure SQL 数据库的应用程序应使用最新的连接提供程序，例如最新的 OLE DB 驱动程序或 ODBC 驱动程序。
建议
| 建议 | 好处 |
|---|---|
| 诊断并排查 CPU 使用率过高的问题。 | Azure SQL 数据库提供了内置工具，用于识别 CPU 使用率高的原因并优化工作负荷性能。 |
| 了解阻塞和死锁问题。 | 由于并发 和 由于死锁 而终止的会话导致阻塞的原因和结果不同。 |
| 优化应用程序和数据库以提升性能。 | 优化应用程序和数据库以提高性能。 查看最佳做法。 |
| 根据需要查看Azure 门户利用率报告和缩放。 | 部署后，使用Azure 门户中的内置报告定期查看峰值和平均数据库利用率以及大小调整或缩减大小。 可以轻松缩放 单一数据库 或 弹性池 ，且 不会丢失数据，且停机时间最短。 |
| 查看性能建议。 | 在Azure 门户的数据库页的“智能性能”菜单中，查看并考虑对任何性能建议执行的操作，并实现任何索引、架构和参数化问题。 |
| 查看查询性能见解。 | 查看查询性能见解，了解Azure SQL 数据库报表，以确定消耗资源最多的查询、长时间运行的查询等。 |
| 配置 自动优化。 | 通过基于 AI 和机器学习的持续性能优化来提供最佳性能和稳定工作负荷。 请考虑使用Azure 自动化为自动优化配置电子邮件通知。 |
| 评估内存中数据库对象的潜在使用。 | 内存中技术 使你能够提高应用程序的性能，并可能降低数据库的成本。 请考虑在大容量 OLTP 应用程序中设计一些数据库对象。 |
| 利用查询存储。 | 默认情况下，在Azure SQL 数据库中启用查询存储包含大量查询性能和资源消耗数据，以及高级优化功能，例如查询存储提示和自动计划更正。 查看Azure SQL 数据库中的查询存储默认值。 |
| 为暂时性错误实现重试逻辑。 | 应用程序应包括 暂时性错误的自动事务重试逻辑 ，包括常见的连接错误。 利用指数重试间隔逻辑。 |
其他资源
有关支持的功能的信息，请参阅迁移到 SQL 数据库期间的功能和解决 Transact-SQL 差异。
迁移到Azure SQL 数据库？ 查看我们的 Azure 数据库迁移指南。
观看公开的数据集，涵盖 Azure SQL 主题等。
后续步骤
- 尝试使用 Azure 免费帐户免费Azure SQL 数据库，然后开始使用 Azure SQL 数据库 中的单一数据库。