查询分析基础结构

SQL Server 数据库引擎 提供了访问查询执行计划的运行时信息的功能。 出现性能问题时，最重要的操作之一是准确了解正在执行的工作负载以及如何驱动使用资源。 为此，访问实际执行计划是很重要的。

虽然查询完成是实际查询计划可用性的先决条件，但实时查询统计信息可以提供对查询执行过程的实时见解，因为数据是从一个查询计划运算符移动到另一个。 实时查询计划显示总体查询进度和操作员级运行时执行统计信息（例如处理的行数、经过的时间、操作员进度等）。由于此数据是实时可用的，无需等待完成查询，因此这些执行统计信息对于调试查询性能问题非常有用，例如长时间运行查询以及无限期运行而从未完成过的查询。

标准查询执行统计信息分析基础结构

必须启用查询执行统计信息配置文件基础结构或标准分析，以收集有关执行计划的信息，即行数、CPU 和 I/O 使用情况 。 以下收集目标会话的执行计划信息的方法利用标准分析基础结构：

备注

单击 SQL Server Management Studio 中的“包含实时查询统计信息”按钮可以利用标准分析基础结构 。
在更高版本的 SQL Server 中，如果启用了轻量级分析基础结构，则在通过活动监视器查看或直接查询 sys.dm_exec_query_profiles DMV 时通过实时查询统计信息而非标准分析加以利用。

以下为所有会话全局收集执行计划信息的方法利用标准分析基础结构：

当运行使用 query_post_execution_showplan 事件的扩展事件会话时，还会填充 sys.dm_exec_query_profiles DMV，它使用活动监视器或直接查询 DMV，为所有会话启用实时查询统计。 有关详细信息，请参阅 Live Query Statistics。

轻型查询执行统计信息分析基础结构

从 SQL Server 2014 (12.x) SP2 和 SQL Server 2016 (13.x) 开始，引入了新的轻型查询执行统计信息概要分析基础结构或轻型分析 。

备注

本机编译存储过程不支持轻型分析。

轻型查询执行统计信息分析基础结构 v1

适用对象：SQL Server（SQL Server 2014 (12.x) SP2 到 SQL Server 2016 (13.x)）。

从 SQL Server 2014 (12.x) SP2 和 SQL Server 2016 (13.x) 开始，通过引入轻型分析，减少了收集执行计划信息的性能开销。 和标准分析不同，轻型分析不收集 CPU 运行时信息。 但是，轻型分析仍收集行计数和 I/O 使用情况信息。

还引入了一个新的利用轻型分析的 query_thread_profile 扩展事件。 此扩展事件公开了每个运算符的执行统计信息，从而可以更深入地了解每个节点和线程的性能。 使用此扩展事件的示例会话可以按下面的示例进行配置：

SQL复制

CREATE EVENT SESSION [NodePerfStats] ON SERVER
ADD EVENT sqlserver.query_thread_profile(
  ACTION(sqlos.scheduler_id,sqlserver.database_id,sqlserver.is_system,
    sqlserver.plan_handle,sqlserver.query_hash_signed,sqlserver.query_plan_hash_signed,
    sqlserver.server_instance_name,sqlserver.session_id,sqlserver.session_nt_username,
    sqlserver.sql_text))
ADD TARGET package0.ring_buffer(SET max_memory=(25600))
WITH (MAX_MEMORY=4096 KB,
  EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
  MAX_DISPATCH_LATENCY=30 SECONDS,
  MAX_EVENT_SIZE=0 KB,
  MEMORY_PARTITION_MODE=NONE,
  TRACK_CAUSALITY=OFF,
  STARTUP_STATE=OFF);

备注

有关查询分析的性能开销的详细信息，请参阅博客文章Developers Choice:Query progress - anytime, anywhere（开发人员之选：随时随地查询进度）。

当运行使用 query_thread_profile 事件的扩展事件会话时，还会使用轻型分析填充 sys.dm_exec_query_profiles DMV，它使用活动监视器或直接查询 DMV，为所有会话启用实时查询统计。

轻型查询执行统计信息分析基础结构 v2

适用对象：SQL Server（SQL Server 2016 (13.x) SP1 到 SQL Server 2017 (14.x)）。

SQL Server 2016 (13.x) SP1 包括具有最小开销的轻型分析的修订版本。 对于“适用范围” 中提到的上述版本，使用跟踪标志 7412也可以全局启用轻型分析。 引入了新的 DMF sys.dm_exec_query_statistics_xml 以返回正在进行的请求的查询执行计划。

从 SQL Server 2016 (13.x) SP2 CU3 和 SQL Server 2017 (14.x) CU11 开始，如果未全局启用轻型分析，则可以使用新的 USE HINT查询提示参数 QUERY_PLAN_PROFILE 以查询级别启用轻型分析，且适用于任何会话。 当包含此新提示的查询完成时，还会输出新的 query_plan_profile 扩展事件，该事件提供类似于 query_post_execution_showplan 扩展事件的实际执行计划 XML。

备注

即使未使用查询提示，query_plan_profile 扩展事件也会利用轻量分析 。

使用 query_plan_profile 扩展事件的示例会话可以像下面的示例一样进行配置 ：

SQL复制

CREATE EVENT SESSION [PerfStats_LWP_Plan] ON SERVER
ADD EVENT sqlserver.query_plan_profile(
  ACTION(sqlos.scheduler_id,sqlserver.database_id,sqlserver.is_system,
    sqlserver.plan_handle,sqlserver.query_hash_signed,sqlserver.query_plan_hash_signed,
    sqlserver.server_instance_name,sqlserver.session_id,sqlserver.session_nt_username,
    sqlserver.sql_text))
ADD TARGET package0.ring_buffer(SET max_memory=(25600))
WITH (MAX_MEMORY=4096 KB,
  EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
  MAX_DISPATCH_LATENCY=30 SECONDS,
  MAX_EVENT_SIZE=0 KB,
  MEMORY_PARTITION_MODE=NONE,
  TRACK_CAUSALITY=OFF,
  STARTUP_STATE=OFF);

轻型查询执行统计信息分析基础结构 v3

适用对象：SQL Server（从 SQL Server 2019（预览版） 开始）

SQL Server 2019（预览版） 包括一个新修订的轻型分析版本，用于收集所有执行的行计数信息。 默认情况下，SQL Server 2019（预览版） 中已启用轻型分析，跟踪标志 7412 无效。 可以使用 LIGHTWEIGHT_QUERY_PROFILING 数据库范围配置 ALTER DATABASE SCOPED CONFIGURATION SET LIGHTWEIGHT_QUERY_PROFILING = OFF; 在数据库级别禁用轻量级分析。

引入了新的 DMF sys.dm_exec_query_plan_stats 以返回大多数查询的最后已知实际执行计划的等效项，称为“最后查询计划统计信息” 。 可以使用 LAST_QUERY_PLAN_STATS 数据库范围配置 ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON; 在数据库级别启用最后查询计划统计信息。

新的 query_post_execution_plan_profile 扩展事件基于轻型分析收集实际执行计划的等效项，与使用标准分析的 query_post_execution_showplan 不同 。 可以像如下所示对使用 query_post_execution_plan_profile 扩展事件的示例会话进行配置 ：

SQL复制

CREATE EVENT SESSION [PerfStats_LWP_All_Plans] ON SERVER
ADD EVENT sqlserver.query_post_execution_plan_profile(
  ACTION(sqlos.scheduler_id,sqlserver.database_id,sqlserver.is_system,
    sqlserver.plan_handle,sqlserver.query_hash_signed,sqlserver.query_plan_hash_signed,
    sqlserver.server_instance_name,sqlserver.session_id,sqlserver.session_nt_username,
    sqlserver.sql_text))
ADD TARGET package0.ring_buffer(SET max_memory=(25600))
WITH (MAX_MEMORY=4096 KB,
  EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
  MAX_DISPATCH_LATENCY=30 SECONDS,
  MAX_EVENT_SIZE=0 KB,
  MEMORY_PARTITION_MODE=NONE,
  TRACK_CAUSALITY=OFF,
  STARTUP_STATE=OFF);

示例 1 - 使用标准分析的扩展事件会话

SQL复制

CREATE EVENT SESSION [QueryPlanOld] ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan(
    ACTION(sqlos.task_time, sqlserver.database_id,
    sqlserver.database_name, sqlserver.query_hash_signed,
    sqlserver.query_plan_hash_signed, sqlserver.sql_text))
ADD TARGET package0.event_file(SET filename = N‘C:\Temp\QueryPlanStd.xel‘)
WITH (MAX_MEMORY=4096 KB, EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
    MAX_DISPATCH_LATENCY=30 SECONDS, MAX_EVENT_SIZE=0 KB,
    MEMORY_PARTITION_MODE=NONE, TRACK_CAUSALITY=OFF, STARTUP_STATE=OFF);

示例 2 - 使用轻型分析的扩展事件会话

SQL复制

CREATE EVENT SESSION [QueryPlanLWP] ON SERVER
ADD EVENT sqlserver.query_post_execution_plan_profile(
    ACTION(sqlos.task_time, sqlserver.database_id,
    sqlserver.database_name, sqlserver.query_hash_signed,
    sqlserver.query_plan_hash_signed, sqlserver.sql_text))
ADD TARGET package0.event_file(SET filename=N‘C:\Temp\QueryPlanLWP.xel‘)
WITH (MAX_MEMORY=4096 KB, EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
    MAX_DISPATCH_LATENCY=30 SECONDS, MAX_EVENT_SIZE=0 KB,
    MEMORY_PARTITION_MODE=NONE, TRACK_CAUSALITY=OFF, STARTUP_STATE=OFF);

Remarks

重要

由于在执行引用 sys.dm_exec_query_statistics_xml 的监视存储过程时可能存在随机 AV，因此请确保在 SQL Server 2016 (13.x) 和 SQL Server 2017 (14.x) 中安装了 KB 4078596。

从轻型分析 v2 开始，其开销很低，任何尚未受 CPU 限制的服务器都可连续运行轻型分析，并允许数据库专业人员随时使用任何正在运行的执行，例如使用活动监视器或直接查询 sys.dm_exec_query_profiles，并获取运行时统计信息的查询计划 。

有关查询分析的性能开销的详细信息，请参阅博客文章Developers Choice:Query progress - anytime, anywhere（开发人员之选：随时随地查询进度）。

备注

利用轻型分析的扩展事件将使用来自标准分析的信息，以防早已启用了标准分析基础结构。 例如，使用 query_post_execution_showplan 的扩展事件会话正在运行，而另一个使用 query_post_execution_plan_profile 的会话已启动。第二个会话仍将使用来自标准分析的信息。

原文地址：https://www.cnblogs.com/PerfectBeauty/p/11093150.html

时间： 2024-08-01 12:58:36

查询分析基础结构的相关文章

mysql性能优化-慢查询分析、优化索引和配置

一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)      key_buffer_size 5)      query_cache_size 6)      record_buffer_size 7)      read_rnd_buffer

MySQL的慢查询分析

慢查询分析日最初是用来捕获比较“慢”的查询,在mysql5.1 + 版本中,慢查询的功能被加强,可以通过设置long_query_time为0来捕获所有的查询,而且查询的响应时间已经可以做到微妙级别. ---在MySQL的当前版本中,慢查询日志是开销最低,精确度最高的测量查询时间的工具.如果还在担心开启慢查询会带来额外的I/O开销,那大可以放心,我们在I/O密集型场景做过测试,慢查询带来的开销可以忽略不计(实际上CPU密集型场景的影响还稍大一些) 更需要担心的是日志可能会消耗掉很大的磁盘空间,因

[转]一个用户SQL慢查询分析，原因及优化

来源:http://blog.rds.aliyun.com/2014/05/23/%E4%B8%80%E4%B8%AA%E7%94%A8%E6%88%B7sql%E6%85%A2%E6%9F%A5%E8%AF%A2%E5%88%86%E6%9E%90%EF%BC%8C%E5%8E%9F%E5%9B%A0%E5%8F%8A%E4%BC%98%E5%8C%96/ 问题描述 一个用户反映先线一个SQL语句执行时间慢得无法接受.SQL语句看上去很简单(本文描述中修改了表名和字段名):SELECT cou

mysql慢查询分析

mysql慢查询分析 Posted: 29. 08. 2014 | Author: zdz | Category: mysql MySQL 慢查询日志分析 1. pt-query-digest分析慢查询日志pt-query-digest –report slow.log 2. 报告最近半个小时的慢查询:pt-query-digest –report –since 1800s slow.log 3. 报告一个时间段的慢查询:pt-query-digest –report –since '2013-

mysql慢查询分析工具和分析方法

1.mysql慢查询分析工具 1.参考文档: http://www.ttlsa.com/mysql/analyse-slow-query-log-using-anemometer/ http://isadba.com/?p=655 官方文档: https://github.com/box/Anemometer 数据库管理员一般是用percona的toolkit工具来分析MySQL慢查询记录,但是不够直观. 下面介绍一款比较直观的工具来统计分析MySQL慢查询记录anemometer. 在使用之前

MongoDB 查询分析

MongoDB 查询分析可以确保我们建议的索引是否有效,是查询语句性能分析的重要工具. MongoDB 查询分析常用函数有:explain() 和 hint(). 使用 explain() explain 操作提供了查询信息,使用索引及查询统计等.有利于我们对索引的优化. 接下来我们在 users 集合中创建 gender 和 user_name 的索引: >db.users.ensureIndex({gender:1,user_name:1}) </p> <p>现在在查询语

Linux下MySQL慢查询分析mysqlsla安装使用

说明: 操作系统:CentOS 5.X 64位 MySQL版本:mysql-5.5.35 MySQL配置文件:/etc/my.cnf MySQL 数据库存放目录:/data/mysql 实现目的:开启MySQL慢查询日志功能,安装使用MySQL慢查询分析mysqlsla 具体操作: 一.开启MySQL慢查询功能 mysql -u  root -p  #进入MySQL控制台 show variables like '%slow%';   #查看MySQL慢查询是否开启 set global slo

让MySoft.Data也能有Discuz!NT的数据库查询分析工具

当我们用Debug模式运行Discuz!NT项目的时候,我们会发现在页面的最下方有一个数据查询分析工具,非常的方便.当我们运行一个页面的时候,对sql的操作可以一目了然.当然,有些还是无法显示在页面上的,比如多个跳转的时候,最终显示的就只有一个页面的sql.不过也挺方便了. 如图: 这个数据库查询分析工具,只有在Debug模式下才会显示,Release模式不会显示. 这样的做法有两个好处,一是方便调试,第二是每当发布站点的时候,一定是Release模式的,可以确保站点在运行效率上有保证(很多时候

MongoDB查询分析

MongoDB 查询分析可以确保我们建立的索引是否有效,是查询语句性能分析的重要工具.MongoDB 查询分析常用函数有:explain() 和 hint(). 1. explain(): 提供查询信息,使用索引及查询统计,有利于我们对索引的优化. 使用示例: db.users.find({gender:"M"},{user_name:1,_id:0}).explain() 2. hint(): 强迫MongoDB使用一个指定的索引(为了提高查询性能) 使用示例: db.users.f