适用于：
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 数据库会自动备份数据库。 平台每周进行一次完整备份，每隔几小时进行一次差分备份，每五分钟备份一次日志，以确保灾难恢复高效且数据丢失最小。 创建数据库后，首次完整备份会立即发生。 你可以在一个称为 保留期的内段时间访问这些备份，这取决于你选择的服务等级。 您可以使用时间点恢复（PITR）将数据恢复到此保留期内的任意时间点。
此外，长期 保留备份 功能允许您保存备份文件长达10年，并在该期间的任何时间点恢复备份数据。 Azure将数据库备份保存在地理复制存储中，以增强区域灾难的韧性。 你也可以在任何 Azure 区域内，在保留期内的任何时间恢复这些备份。 有关详细信息，请参阅 Azure SQL 数据库中的业务连续性。
如何在发生数据中心级灾难或区域灾难时确保业务连续性？
将数据库备份存储在地理复制存储中，以确保在区域灾难发生时，您可以将备份恢复到另一个 Azure 区域。 此功能称为 geo-restore。 有关异地还原的详细信息和时间安排，请参阅 Azure SQL 数据库的异地还原。
对于任务关键型数据库，Azure SQL 数据库提供活动异地复制，从而在另一区域中创建原始数据库的异地复制辅助副本。 例如，如果你的数据库最初托管在 Azure 中国北部 2 区域，并且你需要区域容灾能力，请将该数据库的活动异地副本从中国北部 2 创建到中国东部 2。 当灾难袭击中国北部 2 时，可以故障转移到中国东部 2 区域。
除了主动的地理复制，故障切换组还帮助你管理一组数据库的复制和故障切换。 可以创建一个故障转移组，其中包含相同或不同区域中的多个数据库。 随后可以启动将故障转移组中的所有数据库故障转移到次要区域。 有关详细信息，请参阅故障转移组概述与最佳实践（Azure SQL 数据库）。
若要实现数据中心或可用性区域故障的复原能力，请确保为数据库或弹性池启用区域冗余。
主动监视应用程序的灾难情况，并启动故障转移到次要区域。 可以在不同的 Azure 区域中最多创建 4 个此类活动异地副本。 情况变得更好了。 你还可以访问这些次级主动地理复制品以实现只读访问，这有助于降低地理分布应用场景的延迟。
SQL 数据库的灾难恢复是什么样的？
当你使用主动地理复制或故障切换组时，只需在 Azure SQL 数据库 中几个步骤即可配置灾难恢复策略。 你仍必须监视应用程序及其数据库是否存在任何区域灾难，并故障转移到次要区域以恢复业务连续性。
有关详细信息，请参阅 Azure SQL 数据库灾难恢复 101。
安全性与符合性
Azure SQL 数据库 在数据库层面和平台层面都提供安全保障。 您可以通过以下功能控制并提供应用的最佳安全性：
- 身份与认证（SQL认证及Microsoft Entra ID认证）。
- 监视活动（审核和威胁检测）。
- 保护实际数据（透明数据加密 [TDE] 和 始终加密）。
- 控制对敏感和特权数据的访问（行级安全和动态数据掩蔽）。
Microsoft Defender for Cloud 为 Azure、本地和其他云中运行的工作负载提供集中式安全管理。 可以查看审核和透明数据加密 [TDE] 等基本 SQL 数据库保护是否在所有资源上配置，并根据自己的要求创建策略。
SQL 数据库提供哪些用户认证方法？
SQL 数据库提供两种认证方法：
Windows 身份验证不受支持。 Microsoft Entra ID 是一种集中式标识和访问管理服务。 Microsoft Entra ID 提供对组织中的人员的单一登录（SSO）访问权限。 这意味着凭证会在 Azure 服务间共享，以便更便捷地进行认证。
Microsoft Entra ID 支持多因素认证，并且可以轻松与 Microsoft Entra Connect Sync 集成。该集成还使 Azure SQL 数据库 能够在 Microsoft Entra 域内提供多因素认证和访客用户账户。 如果你已经在使用一个本地 Active Directory，则可以将其与 Microsoft Entra ID 联合在一起，以将目录扩展到 Azure。
SQL 身份验证仅支持用户名和密码，以便对给定服务器上的任何数据库的用户进行身份验证。
| 如果你...... | ...用途 |
|---|---|
| 在本地 SQL Server 上使用 AD | 将 AD 与 Microsoft Entra ID 联合在一起，并使用 Microsoft Entra 身份验证。 联合身份验证允许使用单一登录。 |
| 需要强制实施多重身份验证 | 要求多重身份验证作为策略通过 条件访问，并使用 Microsoft Entra 多重身份验证。 |
| 已使用联合域中的 Microsoft Entra 凭据登录到 Windows | 使用 Microsoft Entra 身份验证。 |
| 使用来自未与 Azure 联合身份验证的域的凭据登录到 Windows | 使用 Microsoft Entra 集成身份验证。 |
| 拥有需要连接到 SQL 数据库的中间层服务 | 使用 Microsoft Entra 集成身份验证。 |
| 具有使用 SQL 身份验证的技术要求 | 使用 SQL 身份验证 |
如何限制或控制对数据库的连接访问？
为了组织应用中的连接性，请使用以下技术：
- 防火墙规则
- 虚拟网络服务终结点
- 预留 IP地址
防火墙
默认情况下，逻辑SQL服务器不允许所有数据库连接，除非（可选）来自其他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 密钥保管库、Windows 证书存储和本地硬件安全模块。
| 特征 | 始终加密 (Always Encrypted) | 透明数据加密 |
|---|---|---|
| 加密范围 | 端到端 | 静态数据 |
| 服务器可访问敏感数据 | 否 | 是，因为加密针对静态数据 |
| 允许的 T-SQL 操作 | 相等性比较 | 所有 T-SQL 外围应用可用 |
| 使用此功能所要做出的应用更改 | 最少 | 最少 |
| 加密粒度 | 列级别 | 数据库级别 |
如何限制对数据库中敏感数据的访问？
每个应用数据库中都有敏感数据，你需要保护这些数据不被所有人看到。 组织内某些人员需要查看这些数据，但其他人则不应该。 在这种情况下，你需要隐藏敏感数据，或者根本不公开。 SQL 数据库提供两种防止未授权用户查看敏感数据的方法：
动态数据掩蔽 是一种数据掩蔽功能，您可以通过非特权用户隐藏敏感数据来限制敏感数据的暴露。 你定义了一个遮蔽规则，创建遮蔽模式。 例如，你只能显示国家身份证号码
XXX-XX-0000的最后四位数字，其余部分用X字符掩盖。 使用动态数据掩蔽，你可以识别哪些用户被排除在掩蔽规则之外，并能看到未遮罩的数据。 掩蔽是实时进行的，针对不同数据类别提供了各种遮罩功能。通过行级别安全性 ，可以在行级别控制访问权限。 该功能根据执行查询的用户（组成员身份或执行上下文）隐藏数据库表中的某些行。 访问限制是在数据库层执行的，而不是应用层，这样简化了应用逻辑。 你首先创建一个谓词，过滤掉未暴露的行。 然后，你需要创建安全策略，以定义谁可以访问这些行数据。 最后，终端用户运行查询，根据用户权限，他们要么看到这些受限行，要么根本看不到。
如何在云中管理加密密钥？
始终加密（客户端加密）和透明数据加密（静止加密）都提供 客户管理的密钥 选项。 定期更换加密密钥。 选择与你内部组织法规和合规要求一致的轮换频率。
透明数据加密 (TDE)
TDE 采用双密钥层次结构。 每个用户数据库的数据都由对称的AES-256数据库唯一加密密钥（DEK）加密，该密钥由服务器独一无二的RSA 2048主密钥加密。 主密钥的管理方式可以是：
- 由 Azure SQL 数据库自动执行
- 或者，使用 Azure 密钥保管库 作为密钥存储
默认情况下，Azure SQL 数据库 管理 TDE 主密钥。 如果你的组织想控制主密钥，可以使用 Azure 密钥保管库 作为密钥存储。 通过使用 Azure 密钥保管库，组织假定控制密钥预配、轮换使用和权限控制。 轮换或切换 TDE 主密钥类型非常快，因为它仅重新加密 DEK。 对于安全与数据管理角色分离的组织，安全管理员可以在 Azure 密钥保管库 中配置 TDE 主密钥的密钥材料，并为数据库管理员提供 Azure 密钥保管库 密钥标识符，用于服务器上的静态加密。 密钥保管库的设计可确保 Azure 不会看到或提取任何加密密钥。 此外，可对组织的密钥进行集中式管理。
始终加密 (Always Encrypted)
Always Encrypted 也采用 双密钥层级结构。 敏感数据列由AES 256列加密密钥（CEK）加密，而该密钥又由列主密钥（CMK）加密。 为 Always Encrypted 提供的客户端驱动程序在 CMK 长度上没有任何限制。 CEK 的加密值存储在数据库中，而 CMK 存储在受信任的密钥存储库中，如 Windows 证书存储、Azure 密钥保管库 或硬件安全模块。
轮换 CEK 和 CMK。
CEK 轮换是有一定规模的数据操作，根据包含加密列的表大小，此操作可能十分耗时。 相应地安排CEK轮转。
CMK 轮换不会影响数据库性能，而且可以通过分开的角色来实现。
下图显示了 Always Encrypted 中列主密钥的密钥存储选项：
如何优化和保护组织与 SQL 数据库之间的流量？
你的组织与SQL数据库之间的网络流量通常通过公共网络路由。 不过，你可以利用 Azure ExpressRoute 优化并提升安全性。 ExpressRoute通过私有连接将您的企业网络扩展到Azure平台，绕过公共互联网。 此外，还可以获得更高的安全性、可靠性和路由优化，这带来了较低的网络延迟和更快的速度，比通过公共互联网时通常的体验更佳。 如果你计划在组织和 Azure 之间传输大量数据，使用 ExpressRoute 可以带来成本上的优惠。 可以选择三种不同的连接模型在组织与 Azure 之间建立连接：
ExpressRoute 还允许您将既有带宽限制临时提升至 2 倍，无需额外付费。 你也可以使用ExpressRoute配置跨区域连接。 有关 ExpressRoute 连接提供商的列表，请参阅 ExpressRoute 合作伙伴和对等互连位置。 以下文章更详细介绍了 Express Route：
SQL 数据库是否符合任何法规要求，这如何帮助我自己的组织的合规性？
Azure SQL 数据库 符合多项监管要求。 若要查看 SQL 数据库满足的最新符合性集，请访问信任中心并查看对组织非常重要的符合性，以查看 SQL 数据库是否包含在合规Azure服务下。 尽管 SQL 数据库已认证为合规服务，但它有助于符合组织的服务，但不自动保证它。
迁移后的智能数据库监视和维护
迁移数据库到 SQL 数据库后，监控数据库（例如检查资源利用情况或 DBCC 检查），并进行常规维护（例如重建或重组索引、统计数据等）。 SQL 数据库使用历史趋势和记录的指标和统计信息来主动帮助你监视和维护数据库，以便应用程序始终以最佳方式运行。 在某些情况下，Azure SQL 数据库可根据配置设置自动执行维护任务。 监视 SQL 数据库中的数据库需要考虑三个方面：
- 性能监视和优化
- 安全优化
- 成本优化
性能监视和优化
通过使用查询性能洞察，你可以获得针对数据库工作负载的定制建议，使你的应用程序能够保持最佳运行水平。 还可以进行相应的设置，以便自动应用这些建议，避免干扰维护任务的执行。 通过使用 SQL Database Advisor，你可以根据工作负载自动实现索引推荐。 这个功能叫做自动调音。 建议会根据应用程序工作负荷的变化而不断改进，以提供最有价值的建议。 还可以选择手动审查这些建议，并根据自己的判断应用这些建议。
安全优化
SQL 数据库提供可操作的安全建议，帮助您保护数据安全。 它还提供威胁检测功能，用于识别和调查可能对数据库构成潜在威胁的可疑数据库活动。 漏洞评估 是一种数据库扫描和报告服务，你可以用它来大规模监控数据库的安全状态，识别安全风险，并偏离你定义的安全基线。 每次扫描后，它都会提供定制的可操作步骤和修复脚本清单，以及一份评估报告，帮助你满足合规要求。
通过使用 Microsoft Defender for Cloud，你可以识别并快速应用安全建议。
成本优化
Azure SQL 平台分析服务器中数据库的利用历史，以评估并推荐成本优化方案。 这种分析通常需要几周的时间来分析和构建可操作的建议。
你可能会在 Azure SQL Server 中收到成本建议的横幅通知。 欲了解更多信息，请参见“弹性池帮助你管理和扩展Azure SQL 数据库中的多个数据库”以及“Azure SQL 数据库的规划和管理成本”。
如何监视 SQL 数据库中的性能和资源利用率？
您可以通过以下方法监控SQL数据库中的性能和资源利用情况：
Azure 门户
当你选择数据库并在概览面板中选择图表时，Azure门户会显示数据库的利用情况。 可以修改图表以显示多个指标，包括 CPU 百分比、DTU 百分比、数据 IO 百分比、会话百分比和数据库大小百分比。
在此图表中，还可以按资源配置警报。 这些提醒允许您通过电子邮件响应资源状况、写入HTTPS/HTTP端点，或执行操作。 欲了解更多信息，请参见使用 Azure 门户创建 Azure SQL 数据库 警报。
动态管理视图
可以查询 sys.dm_db_resource_stats 动态管理视图，以返回最近一个小时的资源使用统计信息历史记录，也可以查询 sys.resource_stats 系统目录视图，返回过去 14 天的历史记录。
查询性能见解
可以使用查询性能见解查看特定数据库那些排名靠前的资源消耗查询和长时间运行查询的历史记录。 可以通过资源利用率、持续时间和执行频率快速识别 TOP 查询。 可以跟踪查询和检测回归。 此功能需要为数据库启用和激活查询存储。
我注意到性能问题：SQL 数据库故障排除方法与 SQL Server 有何不同？
你用来诊断查询和数据库性能问题的大多数排查技巧，都和本地的 SQL Server 是一样的。 Azure SQL 数据库 使用相同的 SQL 数据库引擎。 然而，Azure 的功能帮助你更容易排查和诊断性能问题。 它还能代表你执行部分纠正措施，在某些情况下主动自动修复。
使用 查询性能洞察（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 数据库可以自动处理某些类的数据损坏，而不会丢失任何数据。 服务在需要时会使用这些内置技术。 如果存在问题，SQL Database 会主动解决。 作为额外的保护层，你可以选择测试备份恢复并运行完整性检查。 欲了解更多信息，请参见 Azure SQL 数据库 中的数据完整性。
自动页面修复 用于修复损坏或存在数据完整性问题的页面。
CHECKSUM 设置始终验证数据库页的完整性。 有关详细信息，请参阅 SQL 数据库中的数据完整性
迁移后的数据移动
如何使用 Azure 门户从 SQL 数据库导出和导入 BACPAC 文件中的数据？
导出：可以从 Azure 门户将 Azure SQL 数据库中的数据库导出为 BACPAC 文件：
导入：您还可以通过 Azure 门户将数据作为 BACPAC 文件导入 Azure SQL 数据库中的数据库：
如何在 SQL 数据库和 SQL Server 之间同步数据？
有关数据同步替代方案的更多信息，请参见 “迁移到替代解决方案”。