通过

Fabric 数据仓库中的查询见解

  • 项目

适用于：✅SQL 分析终结点和 Microsoft Fabric 中的仓库

在 Microsoft Fabric 中，查询见解功能是一种可缩放、可持续且可扩展的解决方案，可以增强 SQL 分析体验。 借助历史查询数据、聚合见解以及对实际查询文本的访问，你可以分析和优化查询性能。 QI 仅提供有关在用户上下文中运行的查询的信息，而不考虑系统查询。

查询见解功能为 30 天的历史查询数据和可操作见解提供中心位置，帮助你做出明智的决策来增强仓库或 SQL 分析终结点的性能。 当 SQL 查询在 Microsoft Fabric 中运行时，查询见解功能会收集并整合其执行数据，为你提供有价值的信息。 你可以查看管理员、成员和参与者角色的完整查询文本。

  • 历史查询数据：查询见解功能存储有关查询执行的历史数据，使你能够跟踪不同时间的变化。 系统查询不会存储在查询见解中。
  • 聚合见解：查询见解功能将查询执行数据聚合为更具可操作性的见解，例如识别长时间运行的查询或最活跃的用户。 这些聚合基于查询形状。 有关详细信息，请参阅如何聚合类似查询来生成见解？

开始之前

你需要能够访问高级容量工作区中的 SQL 分析终结点或仓库，具有参与者权限或更高权限。

何时需要查询见解？

查询见解功能解决了与查询性能和数据库优化相关的几个问题和顾虑，包括：

查询性能分析

  • 查询的历史性能如何？
  • 是否有任何需要关注的长时间运行的查询？
  • 是否可以识别导致性能瓶颈的查询？
  • 我的查询是否使用了缓存？
  • 哪些查询消耗的 CPU 最多？

查询优化

  • 哪些查询经常运行，是否可以改进其性能？
  • 是否能够识别失败的查询或已取消的查询？
  • 是否能够跟踪查询性能在不同时间的变化？
  • 是否有任何查询一直性能不佳？

用户活动监视

  • 谁提交了特定查询？
  • 谁是最活跃用户或查询运行时间最长的用户？

有三个系统视图可以回答这些问题：

可在何处查看查询见解？

自动生成的视图位于 SQL 分析终结点和仓库中的 queryinsights 架构下。 例如，在仓库的 Fabric Explorer 中，可以在“架构”、“queryinsights”、“视图”下找到查询见解视图。

Fabric 资源管理器的屏幕截图，其中显示了在“架构”、“queryinsights”、“视图”下查找查询见解视图的位置。

查询完成执行后，可以在连接到的仓库或 SQL 分析终结点的 queryinsights 视图中看到其执行数据。 如果在 WH_2 上下文中运行跨数据库查询，查询将显示在 WH_2 的查询见解中。 已完成的查询最多可能需要 15 分钟才会出现在查询见解中，具体取决于正在执行的并发工作负载。 查询出现在查询见解中所需的时间随着执行的并发查询的增加而增加。

如何聚合类似查询来生成见解？

如果查询具有相同的形状，即使谓词可能不同，Query Insights 也会认为查询相同。

你可以利用视图中的 query hash 列来分析类似的查询，并向下钻取到每次执行。

例如，以下查询在其谓词参数化后被视为相同：

SELECT * FROM Orders
WHERE OrderDate BETWEEN '1996-07-01' AND '1996-07-31';

and

SELECT * FROM Orders
WHERE OrderDate BETWEEN '2000-07-01' AND '2006-07-31';

示例

识别过去 30 分钟内运行的查询

以下查询使用 queryinsights.exec_requests_history 和内置 USER_NAME() 函数，该函数返回当前的会话用户名。

SELECT * FROM queryinsights.exec_requests_history 
WHERE start_time >= DATEADD(MINUTE, -30, GETUTCDATE())
AND login_name = USER_NAME();

按 CPU 时间确定 CPU 消耗量最高的查询

以下查询返回按分配的 CPU 时间牌列的前 100 个查询。

SELECT TOP 100 distributed_statement_id, query_hash, allocated_cpu_time_ms, label, command
FROM queryinsights.exec_requests_history
ORDER BY allocated_cpu_time_ms DESC;

确定哪些查询是从远程而非缓存中扫描大多数数据

可以确定查询执行期间的大型数据扫描是否拖慢了查询速度，并做出相应调整查询代码的决定。 使用此分析可以比较不同的查询执行，并确定扫描的数据量的差异是否是性能变化的原因。

此外，可以通过检查 data_scanned_memory_mb 和 data_scanned_disk_mb 的总和，并将其与过去执行的 data_scanned_remote_storage_mb 进行比较来评估缓存的使用情况。

注意

数据扫描值可能不会考虑在查询执行中间阶段移动的数据。 在某些情况下，移动的数据大小和处理所需的 CPU 可能大于数据扫描值所指示的大小。

SELECT distributed_statement_id, query_hash, data_scanned_remote_storage_mb, data_scanned_memory_mb, data_scanned_disk_mb, label, command
FROM queryinsights.exec_requests_history
ORDER BY data_scanned_remote_storage_mb DESC;

使用查询文本中的子字符串识别最常运行的查询

以下查询返回与特定字符串匹配的最近查询，按成功执行次数的降序排列。

SELECT * FROM queryinsights.frequently_run_queries
WHERE last_run_command LIKE '%<some_label>%'
ORDER BY number_of_successful_runs DESC;

使用查询文本中的子字符串识别长时间运行的查询

以下查询返回与特定字符串匹配的查询，按查询执行时间中位数的降序排列。

SELECT * FROM queryinsights.long_running_queries
WHERE last_run_command LIKE '%<some_label>%'
ORDER BY median_total_elapsed_time_ms DESC;

相关内容