查找和跟踪活动

  • 11 分钟

维护数据库的很大部分是性能优化。 习惯于在本地数据库上查看的相同日志文件仍然可用于 Azure Database for MySQL/PostgreSQL。

将数据库迁移到 Azure 后，需要继续检查日志文件以确保数据库性能。

本单元中，你将了解 PostgreSQL 和 MySQL 日志文件在 Azure 中的存储位置，以及它们所包含的详细信息级别。

使用服务器日志跟踪数据库活动

Azure Database for MySQL/PostgreSQL 还在服务器日志中记录诊断信息。 服务器日志是 MySQL 和 PostgreSQL 的本机消息日志文件，而不是无法在 Azure Database for MySQL/PostgreSQL 中访问的事务日志文件。 这些文件包含用于调试数据库问题的消息、服务器状态和其他错误信息。 服务器日志将保留最多 7 天，如果服务器日志文件总大小超过 7 GB 则保留时间会更短。

Azure Database for MySQL 和 Azure Database for PostgreSQL 在服务器日志中记录不同的详细信息。 以下部分分别介绍了每个服务的服务器日志。

Azure Database for MySQL 中的服务器日志

在 Azure Database for MySQL 中，服务器日志提供的信息通常可以在 MySQL 服务器上慢查询日志和审核日志中找到。

使用慢查询日志中的信息来帮助查找运行缓慢的查询。 慢查询日志默认禁用。 可以通过将 slow_query_log 服务器参数设置为 ON 来启用它。 使用以下服务器参数配置慢查询日志以确定慢查询的含义：

  • log_queries_not_using_indexes。 此参数为 ON 或 OFF。 将其设置为 ON 可记录可能执行全表扫描而不是索引查找的所有查询。
  • log_throttle_queries_not_using_indexes。 指定每分钟可记录的未使用索引的最大慢查询数目。
  • log_slow_admin_queries。 将此参数设置为 ON 可在日志中包括运行缓慢的管理查询。
  • long_query_time。 可视为运行缓慢的查询的阈值（以秒为单位）。

启用慢查询日志和审核日志之后，日志文件将开始出现在服务器的“服务器日志”页。 每天都会创建一个新的慢查询日志。 单击日志文件即可下载：

Image of the Server logs page for Azure Database for MySQL.

若要启用审核日志记录，请将 audit_log_enabled 服务器参数设置为 ON。 使用以下参数配置审核日志记录：

  • audit_log_events。 指定要审核的事件。 在 Azure 门户中，此参数提供事件的下拉列表，如 CONNECTION、DDL、DML、ADMIN 及其他。
  • audit_log_exclude_users。 此参数是以逗号分隔的用户列表，这些用户的活动不会包括在审核日志中。

如果需要将慢查询日志和审核日志保留七天以上，则需要将其传输到 Azure 存储。 使用服务器的“诊断设置”页，然后选择“+ 添加诊断设置”。 在“诊断设置”页上，选择“存档到存储帐户”，并选择要在其中保存日志文件的存储帐户（此存储帐户必须已存在），再选择“MySqlSlowLogs”和“MySqlAuditLogs”并指定最多 365 天的保留期。 在此期间可以随时从 Azure 存储下载日志文件。 选择“保存”：

Image of the Diagnostic settings page for Azure Database for MySQL.

慢查询日志数据将以 JSON 格式写入名为 insights-logs-mysqlslowlogs 的容器的 blob。 日志文件可能需要长达 10 分钟的时间才能显示在 Azure 存储中。 审核记录也以 JSON 格式存储在 insights-logs-mysqlslowlogs blob 容器中。

Azure Database for PostgreSQL 中的服务器日志

在 Azure Database for PostgreSQL 中，服务器日志包含错误日志和查询日志文件。 使用这些文件中的信息可帮助找到任何错误和低效查询的源。

可以通过将各种 log_ 服务器配置参数设置为 ON 来启用日志记录。 这些参数包括：

  • log_checkpoints。 只要每个数据文件都使用事务日志中的最新信息进行了更新，就会出现检查点。 如果服务器发生故障，则此点通过从事务日志前滚来标记恢复需要在哪个时间开始。
  • log_connection 和 log_disconnections。 这些设置记录每个成功的连接和每个会话的结束。
  • log_duration。 此设置是要记录的每个已完成 SQL 语句的持续时间。
  • log_lock_waits。 此设置记录锁定等待事件。 锁定等待可由应用程序代码中实现不良的事务引起。
  • log_statement_stats。 此设置将有关服务器性能的累计信息写入日志。

Azure Database for PostgreSQL 还提供了更多参数对记录的信息进行微调：

  • log_error_verbosity。 此设置指定记录的每个消息的详细级别。
  • log_retention_days。 这是在删除日志文件之前服务器保留每个日志文件的天数。 默认值为三天，最多可将其设置为七天。
  • log_min_messages 和 log_min_error_statement。 使用这些参数可指定记录语句的警告和错误级别。

与 Azure Database for MySQL 一样，“服务器日志”页上提供了 Azure Database for PostgreSQL 生成的日志文件。 还可以使用“诊断设置”页将日志复制到 Azure 存储。

跟踪查询性能

查询存储是 Azure 提供的一项附加功能，可帮助识别和跟踪性能不佳的查询。 可将其与 Azure Database for PostgreSQL 和 Azure Database for MySQL 一起使用。

启用查询性能跟踪

在 Azure Database for MySQL 中查询存储将信息记录在 mysql 架构中，在 Azure Database for PostgreSQL 中它将信息记录在名为 azure_sys 的数据库中。 查询存储可以捕获两种类型的信息：有关查询执行的数据以及有关等待统计信息的信息。 默认情况下禁用查询存储。 如何启用：

  • 如果使用 Azure Database for MySQL，请将服务器参数 query_store_capture_mode 和 query_store_wait_sampling_capture_mode 设为 ALL。
  • 如果使用 Azure Database for PostgreSQL，请将服务器参数 pg_qs.query_capture_mode 设置为 ALL 或 TOP，并将 pgms_wait_sampling.query_capture_mode 参数设置为 ALL。

分析查询性能数据

可以直接查询由查询存储使用的表。 如果运行 Azure Database for MySQL，请连接到服务器并运行以下查询：

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

如果使用 Azure Database for PostgreSQL，请改为运行以下查询：

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

在这两种情况下，第一个查询将显示最近运行的每个查询的文本，以及大量有关编译和执行查询所花时间的统计信息。 第二个查询显示有关等待事件的信息。 当一个查询由于需要其他查询所持有资源而无法运行时，将发生等待事件。

如果直接查看查询存储，则可以生成自己的自定义报告，并详细了解系统的工作方式。 但是，可用数据量可能不足以让你理解发生的情况。 Azure Database for MySQL/PostgreSQL 提供了另外两个工具来帮助导航浏览此数据 - Query Performance Insight 和 Query Recommendations。

Query Performance Insight 是图形实用工具，可从服务器的 Query Performance Insight 页面获取。 “长时间运行的查询”选项卡显示最长时间运行的查询的统计信息。 指定时间段，并增加到几分钟内。 图例显示每个查询的文本，以及运行查询的持续时间和次数。 该图提供每个查询的持续时间的比较视图。 可以按每个查询的平均时间查看数据，但也可显示每个查询的总时间（持续时间 执行计数）来获得启发。 下图显示示例：

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

“等待统计信息”选项卡显示每个查询的等待事件信息。 将看到查询等待各种资源所花的时间量。

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

等待事件通常分为三个类别：

  • 锁定等待。 如果查询尝试读取或修改被其他查询锁定的数据，则发生此类事件。 如果遇到大量锁定等待，请检查长时间运行的事务，或者检查使用高度限制隔离级别的操作。
  • IO 等待。 如果查询正在执行大量 IO，则发生这种类型的等待。 出现这种等待的原因可能是查询设计不当（请检查 WHERE 子句）、低效联接操作或缺少索引而引发的全表扫描。
  • 内存等待。 如果内存不足而无法处理查询，则出现内存等待。 查询可能尝试读取大量数据，或者它可能受到其他独占内存的查询的阻止。 同样，这可能表示缺少索引，从而导致查询将整个表读入内存中。

这也很可能是因为一种形式的等待触发了另一种，因此不一定要单独检查这些问题。 例如，读取和更新不同表中数据的事务可能受到内存等待的限制。 反过来，此事务可能具有锁定数据，导致另一个事务产生锁定等待。

服务器的“性能建议”页将使用查询存储中保留的信息，并使用它针对工作负荷提供数据库优化建议。