监视和性能优化

Azure SQL 数据库由系统自动管理,它是一个灵活的数据服务,可在其中轻松监视使用情况、添加或删除资源(CPU、内存、I/O)、查找可以提高数据库性能的建议,或者让数据库适应你的工作负荷并自动优化性能。

监视数据库性能

若要监视 Azure 中的 SQL 数据库的性能,首先需要监视所选数据库性能级别相关的资源利用率。 Azure SQL 数据库使得你可以通过查看性能优化建议找到机会来改进和优化查询性能,无需更改资源。 缺少索引与查询优化不足是数据库性能不佳的常见原因。 可以应用这些优化建议来改进你的工作负荷的性能。 还可以通过应用所有已确定的建议并确认它们改进了数据库性能来让 Azure SQL 数据库自动优化查询性能

在监视数据库性能并对其进行故障排除方面,有以下选项可供选择:

Tip

请参阅性能指南,了解在使用上述一种或多种方法识别性能问题后,可以利用哪些技术来提高 Azure SQL 数据库的性能。

使用 Azure 门户监视数据库

Azure 门户中,可以通过选择数据库并单击“监视”图表来监视单一数据库的利用率。 这将显示“指标”窗口,可通过单击“编辑图表”按钮来对其进行更改。 添加以下指标:

  • CPU 百分比
  • DTU 百分比
  • 数据 IO 百分比
  • 数据库大小百分比

添加这些指标后,可以继续在“监视”图表上查看它们,并可在“指标”窗口上查看更多详细信息。 DTU 的平均利用率百分比。 有关服务层的详细信息,请参阅基于 DTU 的购买模型基于 vCore 的购买模型文章。

在服务层监视数据库性能。

还可针对性能指标配置警报。 在“指标”窗口中单击“添加警报”按钮。 按照向导说明来配置警报。 可选择在指标超出或低于特定阈值时显示警报。

例如,如果期望数据库上的工作负荷增长,可选择配置在数据库的任意性能指标达到 80% 时发出电子邮件警报。 可以将此警报用作预警,以确定你何时需要切换到下一个更高的计算大小。

性能指标还可以帮助你确定是否能够降级到更低的计算大小。 假定正在使用标准 S2 数据库,所有性能指标均显示该数据库在任意给定时间的平均使用率都不超过 10%。 采用标准 S1 很可能使该数据库正常工作。 但是,在决定转换到更低的计算大小之前,请注意出现峰值或波动情况的工作负荷。

排查性能问题

若要诊断并解决性能问题,请先了解每个活动查询的状态,以及哪些条件导致出现了与每种工作负荷状态相关的性能问题。 若要提高 Azure SQL 数据库的性能,请了解来自应用程序的每个活动查询请求是处于运行状态还是等待状态。 在 Azure SQL 数据库中排查性能问题时,请在阅读本文以诊断并解决性能问题时注意以下图表。

工作负荷状态

对于出现性能问题的工作负荷,问题的原因可能是 CPU 争用(运行相关的条件)或单个查询正在等待某个资源(等待相关的条件)。

一般原则是,如果 CPU 利用率一贯达到或超过 80%,则表示出现了运行相关的性能问题。 如果出现运行相关的问题,原因可能是 CPU 资源不足,或者出现了与以下条件之一相关的问题:

  • 运行查询过多
  • 编译查询过多
  • 一个或多个执行查询使用了欠佳的查询计划

如果确定遇到了运行相关的性能问题,则目标应是使用一种或多种方法识别确切的问题。 用于标识运行相关问题的最常见方法包括:

  • 使用 Azure 门户监视 CPU 利用率百分比。
  • 使用以下动态管理视图

    • sys.dm_db_resource_stats 返回 Azure SQL 数据库中数据库的 CPU、I/O 和内存消耗量。 即使数据库中没有活动,也会每隔 15 秒返回一行数据。 历史数据将保留一小时。
    • sys.resource_stats 返回 Azure SQL 数据库的 CPU 使用率和存储数据。 在五分钟间隔内收集并聚合数据。

Important

请参阅识别 CPU 性能问题,其中提供了一组使用这些 DMV 排查 CPU 利用率问题的 T-SQL 查询。

识别问题后,可以优化有问题的查询,或升级计算大小或服务层,以增加 Azure SQL 数据库的容量来满足 CPU 要求。 有关缩放单一数据库资源的信息,请参阅缩放 Azure SQL 数据库中的单一数据库资源;有关缩放弹性池资源的信息,请参阅缩放 Azure SQL 数据库中的弹性池资源

确定不存在 CPU 消耗量较高的运行相关性能问题后,则表示出现了等待相关的性能问题。 即,由于 CPU 正在等待其他某个资源,因此 CPU 资源未得到有效利用。 对于这种情况,下一步是识别 CPU 资源正在等待哪个资源。 用于显示最常见的等待类型类别的最常用方法:

  • 查询存储每个查询在不同时间段的等待统计信息。 在查询存储中,等待类型合并成等待类别。 等待类别到等待类型的映射在 sys.query_store_wait_stats 中提供。
  • sys.dm_db_wait_stats 返回有关操作期间执行的线程遇到的所有等待的信息。 可以使用此聚合视图来诊断 Azure SQL 数据库以及特定查询和批的性能问题。
  • sys.dm_os_waiting_tasks 返回有关正在等待某个资源的任务的等待队列的信息。

如上面的图表中所示,是最常见的等待是:

  • 锁(阻塞)
  • I/O
  • tempdb 相关的争用
  • 内存授予等待

Important

有关使用这些 DMV 排查这些等待相关问题的一组 T-SQL 查询,请参阅:

使用更多资源改进数据库性能

最后,如果没有可操作项可以改进数据库性能,你可以更改 Azure SQL 数据库中提供的资源数量。 随时可以通过更改单一数据库的 DTU 服务层或者增加弹性池的 eDTU 数目,来分配更多资源。 或者,如果使用基于 vCore 的购买模型,则可更改服务层或增加分配给数据库的资源。

  1. 对于单一数据库,可以根据需要更改服务层计算资源以提高数据库性能。
  2. 对于多个数据库,请考虑使用弹性池自动调整资源规模。

优化和重构应用程序或数据库代码

你可以更改应用程序代码来以更佳方式使用数据库,更改索引,强制实施计划或使用提示来手动使数据库适合你的工作负荷。 可以在性能指南主题一文中找到有关手动优化和重新编写代码的一些指南和提示。

后续步骤