适用于：
Azure SQL 数据库
从自管理环境迁移到 PaaS（如 Azure SQL 数据库）可能比较复杂。 本文重点介绍适用于单一数据库和共用数据库的 Azure SQL 数据库的主要功能，有助于保持应用程序可用、高性能、安全性和复原能力。
Azure SQL 数据库的核心特征包括：
- 使用 Azure 门户监视数据库
- 业务连续性和灾难恢复 (BCDR)
- 安全性与符合性
- 智能数据库监视和维护
- 数据移动
注意
Microsoft Entra ID 以前称为 Azure Active Directory (Azure AD)。
使用 Azure 门户监视数据库
有关 Azure Monitor 指标和警报，包括建议的警报规则，请参阅使用指标和警报监视 Azure SQL 数据库。 有关服务层级的详细信息，请参阅 基于 DTU 的购买模型概述 和 基于 vCore 的购买模型。
你可以针对性能指标配置警报。 在“指标”窗口中选择“新建预警规则”按钮。 按照向导说明来配置警报。 如果指标超过特定阈值或指标低于特定阈值，则可以发出警报。
例如，如果期望数据库上的工作负荷增长，可选择配置在数据库的任意性能指标达到 80% 时发出电子邮件警报。 可以将此警报用作预警，以确定你何时需要切换到下一个更高的计算大小。
性能指标还可以帮助你确定是否能够降级到更低的计算大小。 但是，在决定转换到更低的计算大小之前，请注意出现峰值或波动情况的工作负荷。
业务连续性和灾难恢复 (BCDR)
业务连续性和灾难恢复能力使你能够在发生灾难时继续业务。 灾难可能是数据库级别的事件（例如，某人错误地删除了某个重要表）或数据中心级别的事件（区域性灾难，例如海啸）。
如何在 SQL 数据库上创建和管理备份？
Azure SQL 数据库会自动备份数据库。 平台每周执行完整备份，每隔几个小时进行差异备份，每隔 5 分钟备份一次日志备份，以确保灾难恢复高效，数据丢失最少。 创建数据库后，首次完整备份会立即发生。 这些备份在称为 保留期的特定时间段内可供你使用，这因所选服务层级而异。 可以使用 时间点恢复（PITR）还原到此保留期内的任何时间点。
此外， 长期保留备份 功能允许将备份文件保留长达 10 年，并在该时间段内的任何时间点从这些备份还原数据。 数据库备份保存在异地复制的存储中，以提供区域灾难的复原能力。 还可以在保留期内的任意时间点恢复 Azure 区域中的任何备份。 有关详细信息，请参阅 Azure SQL 数据库中的业务连续性。
如何在发生数据中心级灾难或区域灾难时确保业务连续性？
数据库备份存储在异地复制的存储中，确保在发生区域性灾难时，可将备份还原到另一个 Azure 区域。 这称为异地还原。 有关异地还原的详细信息和时间安排，请参阅 Azure SQL 数据库的异地还原。
对于任务关键型数据库，Azure SQL 数据库提供活动异地复制，从而在另一区域中创建原始数据库的异地复制辅助副本。 例如，如果数据库最初托管在 Azure 中国北部区域，且需要区域灾难恢复，则需创建中国北部到中国东部的数据库活动异地副本。 当中国北部发生灾难时，可以故障转移到中国东部区域。
除了主动地理复制之外，故障转移组还有助于管理一组数据库的复制和故障转移。 可以创建一个故障转移组，其中包含相同或不同区域中的多个数据库。 随后可以启动将故障转移组中的所有数据库故障转移到次要区域。 有关详细信息，请参阅故障转移组概述与最佳实践（Azure SQL 数据库）。
若要实现数据中心或可用性区域故障的复原能力，请确保为数据库或弹性池启用区域冗余。
主动监视应用程序的灾难情况，并启动故障转移到次要区域。 可以在不同的 Azure 区域中最多创建 4 个此类活动异地副本。 情况变得更好了。 还能以只读方式访问这些辅助活动异地副本。 这有助于降低异地分布式应用程序方案的延迟。
SQL 数据库的灾难恢复是什么样的？
使用活动异地复制或故障转移组时，只需几个步骤，Azure SQL 数据库即可完成灾难恢复的配置和管理。 你仍必须监视应用程序及其数据库是否存在任何区域灾难，并故障转移到次要区域以恢复业务连续性。
有关详细信息，请参阅 Azure SQL 数据库灾难恢复 101。
安全性与符合性
SQL 数据库中的安全性在数据库级别和平台级别可用。 可以控制应用程序并提供最佳安全性，如下所示：
- 标识和认证（SQL 认证及使用 Microsoft Entra ID 进行身份验证）。
- 监视活动（审核和威胁检测）。
- 保护实际数据（透明数据加密 [TDE] 和 始终加密）。
- 控制对敏感和特权数据的访问（行级别安全性和动态数据掩码）。
Microsoft Defender for Cloud 为 Azure、本地和其他云中运行的工作负载提供集中式安全管理。 可以查看审核和透明数据加密 [TDE] 等基本 SQL 数据库保护是否在所有资源上配置，并根据自己的要求创建策略。
SQL 数据库中提供了哪些用户身份验证方法？
SQL 数据库中提供了两种身份验证方法：
Windows 身份验证不受支持。 Microsoft Entra ID 是一种集中式标识和访问管理服务。 这意味着凭据在 Azure 服务之间共享，以便更轻松地进行身份验证。
Microsoft Entra ID 支持多重身份验证，可以轻松与 Windows Server Active Directory 集成。 此外，还允许 SQL 数据库和 Azure Synapse Analytics 在 Microsoft Entra 域中提供多重身份验证和来宾用户帐户。 如果你已经在使用一个本地 Active Directory，则可以将其与 Microsoft Entra ID 联合在一起，以将目录扩展到 Azure。
SQL 身份验证仅支持用户名和密码，以便对给定服务器上的任何数据库的用户进行身份验证。
| 如果你... | SQL 数据库/Azure Synapse Analytics |
|---|---|
| 在本地 SQL Server 上使用 AD | 将 AD 与 Microsoft Entra ID 联合在一起，并使用 Microsoft Entra 身份验证。 联合身份验证允许使用单一登录。 |
| 需要强制实施多重身份验证 | 要求多重身份验证作为策略通过 条件访问，并使用 Microsoft Entra 多重身份验证。 |
| 已使用联合域中的 Microsoft Entra 凭据登录到 Windows | 使用 Microsoft Entra 身份验证。 |
| 使用来自未与 Azure 联合身份验证的域的凭据登录到 Windows | 使用 Microsoft Entra 集成身份验证。 |
| 具有需要连接到 SQL 数据库或 Azure Synapse Analytics 的中间层服务 | 使用 Microsoft Entra 集成身份验证。 |
| 具有使用 SQL 身份验证的技术要求 | 使用 SQL 身份验证 |
如何限制或控制对数据库的连接访问？
你可以自行使用多种方法来获得应用程序的最佳连接组织方式。
- 防火墙规则
- 虚拟网络服务终结点
- 预留 IP地址
防火墙
默认情况下，所有与服务器内数据库的连接均被禁止，除非选择性地允许其他 Azure 服务的连接。 使用防火墙规则，您可以开放服务器访问仅限于您批准的实体（例如，开发人员计算机），通过允许这些计算机的 IP 地址穿过防火墙。 此外，还可指定允许其访问服务器的 IP 范围。 例如，可以在防火墙设置页中指定范围，一次性添加组织中的多个开发人员计算机 IP 地址。
可以在服务器级别或数据库级别创建防火墙规则。 可使用 Azure 门户或通过 SSMS 创建服务器级 IP 防火墙规则。 有关如何设置服务器级和数据库级防火墙规则的详细信息，请参阅 在 SQL 数据库中创建 IP 防火墙规则。
服务终结点
默认情况下，数据库配置为 允许 Azure 服务和资源访问此服务器，这意味着 Azure 中的任何虚拟机都可能尝试连接到数据库。 这些尝试仍必须经过身份验证。 如果不希望任何 Azure IP 访问数据库，则可以禁用 允许 Azure 服务和资源访问此服务器。 此外，还可以配置 虚拟网络服务终结点。
服务终结点允许仅向 Azure 中的自己的专用虚拟网络公开关键 Azure 资源。 此选项消除了对资源的公共访问。 虚拟网络与 Azure 间的流量位于 Azure 主干网络上。 没有服务终结点时，您将会遇到强制隧道数据包路由。 虚拟网络强制组织的 Internet 流量和 Azure 服务流量通过相同的路由。 借助服务终结点，可以优化这一点，因为数据包直接从虚拟网络流向 Azure 主干网络上的服务。
预留 IP地址
另一种方法是为 VM 预配保留 IP，并在服务器防火墙设置中添加这些特定的 VM IP 地址。 通过分配保留 IP，就可以避免通过更改 IP 地址来更新防火墙规则的麻烦。
连接到 SQL 数据库的端口是什么？
SQL 数据库通过端口 1433 进行通信。 若要从企业网络内部建立连接，必须在组织的防火墙设置中添加出站规则。 作为一项准则，应避免在 Azure 边界外部公开端口 1433。
如何监视和调节 SQL 数据库中的服务器和数据库上的活动？
SQL 数据库审核
Azure SQL 数据库审核 会记录数据库事件，并将其写入 Azure 存储帐户中的审核日志文件。 如果你打算深入了解潜在的安全性和策略违规、维护法规合规性等，则审核尤其有用。它允许你定义和配置你认为需要审核的某些类别的事件，并基于这些类别，你可以获取预配置的报表和仪表板来大致了解数据库中发生的事件。
可以在数据库级别或服务器级别应用这些审核策略。 有关详细信息， 请启用 SQL 数据库审核。
威胁检测
通过威胁检测，您可以对通过审核发现的安全或策略违规行为采取行动。 无需安全方面的专业知识即可解决系统中的潜在威胁或违规。 威胁检测还具有一些内置功能，例如 SQL 注入检测，这是攻击数据库应用程序的一种相当常见的方法。 威胁检测运行多个算法集，用于检测潜在漏洞和 SQL 注入攻击，以及异常数据库访问模式（例如从异常位置或不熟悉的主体进行访问）。
如果在数据库中检测到威胁，安全管理人员或其他指定管理员将收到电子邮件通知。 每个通知都会提供可疑活动的详细信息，以及如何进一步调查和缓解威胁的建议。 若要了解如何启用威胁检测，请参阅 “启用威胁检测”。
如何在 SQL 数据库中保护我的数据？
加密是防范入侵者盗取敏感数据的强大机制。 如果入侵者没有解密密钥，已加密的数据对他们而言毫无用处。 因此，它在 SQL 数据库内置的现有安全层之上再增加了一个保护层。 保护 SQL 数据库中的数据时，需要考虑两个方面：
- 在数据和日志文件中静止的数据
- 传输中的数据
默认情况下，在 SQL 数据库中，存储子系统上的数据和日志文件中的静态数据完全且始终通过 透明数据加密 [TDE] 进行加密。 备份也会加密。 使用 TDE 时，应用程序端无需更改即可访问此数据。 顾名思义，加密和解密以透明方式进行。
为了保护传输中和存储中的敏感数据，SQL 数据库提供了一个名为 Always Encrypted 的功能。 Always Encrypted 是客户端加密的一种形式，用于加密数据库中的敏感列（因此它们以密码形式传递给数据库管理员和未经授权的用户）。 服务器首先接收加密的数据。
Always Encrypted 的密钥也存储在客户端，因此只有授权的客户端可以解密敏感列。 服务器和数据管理员无法看到敏感数据，因为加密密钥存储在客户端上。 Always Encrypted 从未经授权的客户端到物理磁盘，对表中的敏感列进行端到端加密。
Always Encrypted 支持相等比较，因此 DBA 可以继续在其 SQL 命令中查询加密列。 Always Encrypted 可以与各种密钥存储选项结合使用，如 Azure Key Vault、Windows 证书存储和本地硬件安全模块。
| 特征 | 始终加密 (Always Encrypted) | 透明数据加密 |
|---|---|---|
| 加密范围 | 端到端 | 静态数据 |
| 服务器可访问敏感数据 | 否 | 是，因为加密针对静态数据 |
| 允许的 T-SQL 操作 | 相等性比较 | 所有 T-SQL 外围应用可用 |
| 使用此功能所要做出的应用更改 | 最少 | 最少 |
| 加密粒度 | 列级别 | 数据库级别 |
如何限制对数据库中敏感数据的访问？
每个应用程序的数据库都有需要受到保护的敏感数据，以防止被所有人看到。 组织中的特定人员需要查看此数据，但是，其他人不应能够查看此数据。 在这种情况下，需要屏蔽敏感数据，或者根本不公开敏感数据。 SQL 数据库提供以下两种方案用于防止未经授权的用户查看敏感数据：
动态数据掩 码是一项数据掩码功能，通过对应用程序层上的非特权用户屏蔽敏感数据，可以限制敏感数据的公开。 定义一个掩码规则，该规则可以创建掩码模式（例如，仅显示国家 ID SSN 的最后四位数字：
XXX-XX-0000并用字符屏蔽大部分X数据）并标识要从掩码规则中排除的用户。 掩码是即时发生的，对于不同的数据类别，可以使用不同的掩码功能。 动态数据掩码可以自动检测数据库中的敏感数据并对其应用掩码。通过行级别安全性 ，可以在行级别控制访问权限。 这意味着，可以根据执行查询的用户（组成员或执行上下文）来隐藏数据库表中的某些行。 访问限制是在数据库层上完成的，而不是在应用层，以此简化你的应用逻辑。 首先创建筛选器谓词，过滤掉不要公开的行和安全策略，然后定义有权访问这些行的用户。 最后，最终用户运行其查询，根据用户所拥有的权限，他们要么可以查看受限制的行，要么完全无法查看。
如何在云中管理加密密钥？
Always Encrypted（客户端加密）和透明数据加密（静态加密）都有密钥管理选项。 建议定期轮换加密密钥。 轮换频率应与内部组织法规与符合性要求一致。
透明数据加密 (TDE)
TDE 中存在一个双密钥层次结构 - 每个用户数据库中的数据通过对称 AES-256 数据库唯一的数据库加密密钥 (DEK) 进行加密，该密钥反过来又由服务器唯一的非对称 RSA 2048 主密钥进行加密。 主密钥的管理方式可以是：
- 由 Azure SQL 数据库自动执行
- 或者，使用 Azure Key Vault 作为密钥存储
默认情况下，TDE 的主密钥由 Azure SQL 数据库管理。 如果组织希望控制主密钥，则可以使用 Azure Key Vault 作为密钥存储。 通过使用 Azure Key Vault，组织假定控制密钥预配、轮换使用和权限控制。 轮换或切换 TDE 主密钥类型非常快，因为它仅重新加密 DEK。 对于安全性与数据管理角色分开的组织来说，安全管理员可以为 Azure Key Vault 中的 TDE 主密钥预配密钥材料，并为数据库管理员提供 Azure Key Vault 密钥标识符，用于在服务器上进行静态加密。 密钥保管库的设计可确保 Azure 不会看到或提取任何加密密钥。 此外，可对组织的密钥进行集中式管理。
始终加密 (Always Encrypted)
Always Encrypted 中还有两个密钥层次结构 - 一列敏感数据通过 AES 256 列加密密钥 (CEK) 加密，而该密钥反过来又由列主密钥 (CMK) 进行加密。 为 Always Encrypted 提供的客户端驱动程序在 CMK 长度上没有任何限制。 CEK 的加密值存储在数据库中，而 CMK 存储在受信任的密钥存储库中，如 Windows 证书存储、Azure Key Vault 或硬件安全模块。
CEK 和 CMK 都可以旋转。
CEK 轮换是有一定规模的数据操作，根据包含加密列的表大小，此操作可能十分耗时。 因此，明智的做法是相应地规划 CEK 轮换。
但是，CMK 轮换不会影响数据库性能，并可以使用单独的角色来完成。
下图显示了 Always Encrypted 中列主密钥的密钥存储选项：
如何优化和保护组织与 SQL 数据库之间的流量？
组织与 SQL 数据库之间的网络流量通常通过公用网络路由。 但是，可以优化此路径，并使它使用 Azure ExpressRoute 更安全。 ExpressRoute 通过专用连接将企业网络扩展到 Azure 平台。 这样，就不需要经由公共 Internet。 此外，还可以获得更高的安全性、可靠性和路由优化，这带来了较低的网络延迟和更快的速度，比通过公共互联网时通常的体验更佳。 如果打算在组织与 Azure 之间传输大量的数据区块，则使用 ExpressRoute 可带来成本效益。 可以选择三种不同的连接模型在组织与 Azure 之间建立连接：
ExpressRoute 还允许您将既有带宽限制临时提升至 2 倍，无需额外付费。 还可使用 ExpressRoute 来配置跨区域连接。 有关 ExpressRoute 连接提供商的列表，请参阅 ExpressRoute 合作伙伴和对等互连位置。 以下文章更详细介绍了 Express Route：
SQL 数据库是否符合任何法规要求，这如何帮助我自己的组织的合规性？
SQL 数据库符合一系列合规要求。 若要查看 SQL 数据库已满足的最新一组合规性，请访问 信任中心，检查对您组织重要的合规性要求，以确定 SQL 数据库是否符合 Azure 服务合规性要求的列表中。 尽管 SQL 数据库已认证为合规服务，但它有助于符合组织的服务，但不自动保证它。
迁移后的智能数据库监视和维护
将数据库迁移到 SQL 数据库后，应监视数据库（例如，检查资源利用率的方式或 DBCC 检查）并执行定期维护（例如重新生成或重新组织索引、统计信息等）。 SQL 数据库使用历史趋势和记录的指标和统计信息来主动帮助你监视和维护数据库，以便应用程序始终以最佳方式运行。 在某些情况下，Azure SQL 数据库可根据配置设置自动执行维护任务。 监视 SQL 数据库中的数据库需要考虑三个方面：
- 性能监视和优化
- 安全优化
- 成本优化
性能监视和优化
使用 Query Performance Insights，可以针对数据库工作负荷获取定制建议，以便应用程序可以保持最佳级别运行。 还可以进行相应的设置，以便自动应用这些建议，避免干扰维护任务的执行。 借助 SQL 数据库顾问，可以根据工作负荷自动实现索引建议。 这称为自动调谐。 建议会根据应用程序工作负荷的变化而不断改进，以提供最有价值的建议。 还可以选择手动审查这些建议，并根据自己的判断应用这些建议。
安全优化
SQL 数据库提供可行的安全建议，帮助保护数据，威胁检测可用于识别和调查可能对数据库构成威胁的可疑数据库活动。 漏洞评估是一项数据库扫描和报告服务，允许你大规模监视数据库的安全状态、识别安全风险以及偏离你定义的安全基线的行为。 每次扫描后，都会提供可作步骤和修正脚本的自定义列表，以及可用于帮助满足合规性要求的评估报告。
借助 Microsoft Defender for Cloud，可以全面识别安全建议并快速应用这些建议。
成本优化
Azure SQL 平台会分析服务器中数据库的利用率历史记录，作出评估并给出成本优化建议。 这种分析通常需要几周的时间来分析和构建可操作的建议。
你可能会在 Azure SQL Server 中收到成本建议的横幅通知。 有关更多信息，请参阅弹性池有助于在 Azure SQL 数据库中管理和缩放多个数据库。
如何监视 SQL 数据库中的性能和资源利用率？
可以使用以下方法监视 SQL 数据库中的性能和资源利用率：
Azure 门户
Azure 门户通过选择数据库并选择“概述”窗格中的图表来显示数据库的利用率。 可以修改图表以显示多个指标，包括 CPU 百分比、DTU 百分比、数据 IO 百分比、会话百分比和数据库大小百分比。
在此图表中，还可以按资源配置警报。 通过这些警报，可以使用电子邮件响应资源状态，写入 HTTPS/HTTP 终结点或执行操作。 有关详细信息，请参阅 使用 Azure 门户为 Azure SQL 数据库和 Azure Synapse Analytics 创建警报。
动态管理视图
可以查询 sys.dm_db_resource_stats 动态管理视图，以返回最近一个小时的资源使用统计信息历史记录，也可以查询 sys.resource_stats 系统目录视图，返回过去 14 天的历史记录。
查询性能见解
可以使用查询性能见解查看特定数据库那些排名靠前的资源消耗查询和长时间运行查询的历史记录。 可以通过资源利用率、持续时间和执行频率快速识别 TOP 查询。 可以跟踪查询和检测回归。 此功能需要为数据库启用和激活查询存储。
我注意到性能问题：SQL 数据库故障排除方法与 SQL Server 有何不同？
用于诊断查询和数据库性能问题的故障排除技术的主要部分保持不变：相同的数据库引擎为云提供支持。 Azure SQL 数据库可帮助你更轻松地排查和诊断性能问题。 它还可以代表你执行其中一些纠正措施，在某些情况下，主动修复它们。
解决性能问题的方法可以通过结合使用 查询性能见解 （QPI）和 数据库顾问 等智能功能来显著受益，因此方法的差异也不同 -你不再需要手动完成磨出有助于解决当前问题的基本详细信息。 平台会为你承担繁重的工作。 一个例子就是 QPI。 使用 QPI 可以一路深化到查询级别，查看历史趋势并判断查询回归的确切时间。 数据库顾问提供有关有助于提高总体性能（例如缺失索引、删除索引、参数化查询等）的建议。
进行性能故障排除时，请务必确定是应用程序，还是支持它的数据库影响了应用程序的性能。 通常，性能问题出现在应用程序层。 问题原因可能在于体系结构或数据访问模式。 例如，假设你有一个对网络延迟敏感的聊天应用程序。 在这种情况下，应用程序会受到影响，因为在拥堵的网络中，应用程序与服务器之间会有许多频繁的短请求，这些往返很快就会累积起来。 为了改进本例中的性能，可以使用 Batch 查询，这有助于降低往返延迟并提高应用程序的性能。
此外，如果注意到数据库总体性能下降，则可以监视 sys.dm_db_resource_stats 和 sys.resource_stats 动态管理视图，了解 CPU、IO 和内存消耗情况。 如果数据库资源不足，性能可能会受到影响。 可能需要根据工作负荷需求的增长和收缩来更改计算大小和服务层。
有关优化性能问题的一组全面的建议，请参阅 优化数据库。
如何确保使用适当的服务层级和计算大小？
SQL 数据库提供了两种不同的购买模型：较旧的 DTU 模型和更适应的 vCore 购买模型。 有关详细信息，请参阅 比较 Azure SQL 数据库的 vCore 和基于 DTU 的购买模型。
可以在任一购买模型中监视查询和数据库资源消耗量。 有关详细信息，请参阅监视和性能优化。 如果发现查询/数据库一直运行活跃，则可考虑纵向扩展到更高的计算大小。 同样，如果在高峰时段似乎没有那么多使用资源，请考虑缩减当前计算资源规模。 可以考虑使用 Azure 自动化按计划缩放 SQL 数据库。
如果您有 SaaS 应用使用模式或数据库整合方案，考虑使用弹性池来优化成本。 弹性池是实现数据库整合和成本优化的极佳方式。 有关使用弹性池管理多个数据库的详细信息，请参阅 管理池和数据库。
我需要多久对数据库运行一次完整性检查？
SQL 数据库可以自动处理某些类的数据损坏，而不会丢失任何数据。 当需要时，服务会使用这些内置技术。 服务中的数据库备份会定期通过还原和运行DBCC CHECKDB 来进行测试。 如果存在问题，SQL 数据库会主动解决问题。
自动页面修复 用于修复损坏或存在数据完整性问题的页面。 数据库页始终使用用于验证页面完整性的默认设置 CHECKSUM 进行验证。 SQL 数据库主动监视和审查数据库的数据完整性，并在出现问题时解决问题。 可以选择根据需要运行自己的完整性检查。 有关详细信息，请参阅 SQL 数据库中的数据完整性
迁移后的数据移动
如何使用 Azure 门户将数据作为 BACPAC 文件从 SQL 数据库导出和导入？
导出：可以从 Azure 门户将 Azure SQL 数据库中的数据库导出为 BACPAC 文件：
导入：还可以使用 Azure 门户将数据作为 BACPAC 文件导入 Azure SQL 数据库中的数据库：
如何在 SQL 数据库和 SQL Server 之间同步数据？
可通过多种方法实现此目的：
数据同步：此功能有助于在多个 SQL Server 数据库和 SQL 数据库之间双向同步数据。 若要与 SQL Server 数据库同步，需要在本地计算机或虚拟机上安装和配置同步代理，并打开出站 TCP 端口 1433。
事务复制：使用事务复制，可以将数据从 SQL Server 数据库同步到 Azure SQL 数据库，SQL Server 实例是发布服务器，而 Azure SQL 数据库是订阅服务器。 目前仅支持此设置。 有关如何在最短停机时间的情况下将数据从 SQL Server 数据库迁移到 Azure SQL 的详细信息，请参阅 使用事务复制