查询存储功能提供有关 SQL Server、Azure SQL 数据库、Azure SQL 托管实例和 Azure Synapse Analytics 的查询计划选择和性能的见解。查询存储可帮助你快速找到查询计划更改所造成的性能差异，从而简化性能疑难解答。查询存储将自动捕获查询、计划和运行时统计信息的历史记录，并保留它们以供查阅。它按时间窗口将数据分割开来，使你可以查看数据库使用模式并了解服务器上何时发生了查询计划更改。可以使用 ALTER DATABASE SET 选项来配置查询存储。

有关在 Azure SQL 数据库中运行查询存储的信息，请参阅在 Azure SQL 数据库中运行查询存储。
若要详细了解如何使用查询存储发现可操作信息并优化性能，请参阅使用查询存储优化性能。
若要详细了解如何在不更改应用程序代码的情况下调整查询计划，请参阅查询存储提示。
重要

如果仅对 SQL Server 2016 (13.x) 中正在运行的工作负载见解使用查询存储，请尽快安装 KB 4340759 中的性能可伸缩性修补程序。

查询存储存储过程

目录视图

启用查询存储

默认将为新的 Azure SQL 数据库和 Azure SQL 托管实例数据库启用查询存储。
默认不会为 SQL Server 2016 (13.x)、SQL Server 2017 (14.x)、SQL Server 2019 (15.x) 启用查询存储。对于从 SQL Server 2022 (16.x) 开始的新数据库，默认情况下在 READ_WRITE 模式下启用它。若要启用功能以更好地跟踪性能历史记录、排查查询计划相关问题并在 SQL Server 2022 (16.x) 中启用新功能，建议在所有数据库上启用查询存储。
默认不为新的 Azure Synapse Analytics 数据库启用查询存储。

使用 SQL Server Management Studio 中的“查询存储”页面

在对象资源管理器中，右键单击数据库，然后选择“属性”。
备注：至少需要 16 版本的 Management Studio。
在“数据库属性” 对话框中，选择“查询存储” 页。
在“操作模式(要求)”对话框中，选择“读写”。

使用 Transact-SQL 语句

使用 ALTER DATABASE 语句启用给定数据库的查询存储。例如：

ALTER DATABASE <database_name>
SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);

1 2	ALTER DATABASE <database_name> SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);

在 Azure Synapse Analytics 中，无需其他选项即可启用查询存储，例如：

ALTER DATABASE <database_name>
SET QUERY_STORE = ON;

1 2	ALTER DATABASE <database_name> SET QUERY_STORE = ON;

有关与查询存储相关的语法选项的详细信息，请参阅 ALTER DATABASE SET 选项 (Transact-SQL)。

备注

无法为 master 或 tempdb 数据库启用查询存储。

重要

有关启用查询存储并使其适用于你的工作负载，请参阅查询存储最佳做法。

查询存储中的信息

由于统计信息更改、架构更改、索引的创建/删除等多种不同原因，SQL Server 中任何特定查询的执行计划通常会随着时间而改进。过程缓存（其中存储了缓存的查询计划）仅存储最近的执行计划。还会由于内存压力从计划缓存中逐出计划。因此，执行计划更改造成的查询性能回归可能非常重大，且长时间才能解决。

由于查询存储会保留每个查询的多个执行计划，因此它可以强制执行策略，以引导查询处理器对某个查询使用特定执行计划。这称为“计划强制”。查询存储中的计划强制是通过使用类似于 USE PLAN 查询提示的机制来提供的，但它不需要在用户应用程序中进行任何更改。计划强制可在非常短的时间内解决由计划更改造成的查询性能回归。

备注

查询存储收集 DML 语句（如 SELECT、INSERT、UPDATE、DELETE、MERGE 和 BULK INSERT）的计划。

根据设计，查询存储不会收集 CREATE INDEX 等 DDL 语句的计划。查询存储通过收集基础 DML 语句的计划来捕获累积资源消耗。例如，查询存储可能会显示在内部执行的 SELECT 和 INSERT 语句以填充新索引。

默认情况下，查询存储不对本机编译的存储过程收集数据。使用 sys.sp_xtp_control_query_exec_stats 为本机编译的存储过程启用数据收集。

等待统计信息是有助于排除数据库引擎中的性能问题的另一信息来源。长期以来，等待统计信息仅适用于实例级别，难以回溯到特定查询。从 SQL Server 2017（14.x）和 Azure SQL 数据库开始，查询存储包含一个跟踪等待统计信息的维度。下面的示例允许查询存储收集等待统计信息。

ALTER DATABASE <database_name>
SET QUERY_STORE = ON ( WAIT_STATS_CAPTURE_MODE = ON );

1 2	ALTER DATABASE <database_name> SET QUERY_STORE = ON ( WAIT_STATS_CAPTURE_MODE = ON );

使用查询存储功能的常见方案为：

快速查找并修复通过强制使用先前查询计划而造成的计划性能回归。修复近期由于执行计划更改而出现性能回归的查询。
确定在给定时间窗口中查询执行的次数，从而帮助 DBA 对性能资源问题进行故障排除。
标识过去 x 小时内的前 n 个查询（按执行时间、内存占用等）。
审核给定查询的查询计划历史记录。
分析特定数据库的资源（CPU、I/O 和内存）使用模式。
确定资源上正在等待的前 n 个查询。
了解特定查询或计划的等待性质。

查询存储包含三个存储：

计划存储：用于保存执行计划信息。
运行时统计信息存储：用于保存执行统计信息。
等待统计信息存储：用于保存等待统计信息。

max_plans_per_query 配置选项限制了计划存储中查询可存储的唯一计划数。为增强性能，通过异步方式向存储写入信息。为尽量减少空间使用量，将在按固定时间窗口上聚合运行时统计信息存储中的运行时执行统计信息。可通过查询查询存储目录视图来查看这些存储中的信息。

以下查询返回查询存储中查询和计划的相关信息。

SELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id;

SELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*

FROM sys.query_store_plan AS Pl

INNER JOIN sys.query_store_query AS Qry

ON Pl.query_id = Qry.query_id

INNER JOIN sys.query_store_query_text AS Txt

ON Qry.query_text_id = Txt.query_text_id;

次要副本的查询存储

适用于：SQL Server（SQL Server 2022 (16.x) 及更高版本）

次要副本的查询存储功能在次要副本工作负载上启用可用于主要副本的相同的查询存储功能。启用次要副本的查询存储后，副本会将通常存储在查询存储中的查询执行信息发送回主要副本。然后，主要副本会将数据保存到自身查询存储中的磁盘。从本质上讲，主要副本和所有次要副本之间共享有一个查询存储。查询存储存在于主要副本上，将所有副本的数据一起存储。

有关次要副本的查询存储的完整信息，请参阅 Always On 可用性组次要副本的查询存储。

使用回归查询功能

在启用查询存储后，刷新对象资源管理器窗格的数据库部分，以添加“查询存储”部分。

备注

对于 Azure Synapse Analytics，查询存储视图位于对象资源管理器窗格数据库部分的“系统视图”下。

选择“回归查询”，以在 SQL Server Management Studio 中打开“回归查询”窗格。 “回归查询”窗格将显示查询存储中的查询和计划。使用顶部的下拉列表框，根据各种条件筛选查询：持续时间 (ms)（默认）、CPU 时间 (ms)、逻辑读取 (KB)、逻辑写入 (KB)、物理读取 (KB)、CLR 时间 (ms)、DOP、内存消耗 (KB)、行计数、已用日志内存 (KB)、已用临时 DB 内存 (KB) 和等待时间 (ms)。

选择某个计划以查看图形查询计划。可以使用按钮查看源查询、强制执行和取消强制执行查询计划、在网格和图表格式之间进行切换、比较所选的计划（如果选择多个）及刷新显示。

若要强制执行某一计划，请选择查询和计划，然后选择“强制计划”。你只可以强制执行由查询计划功能保存且仍保留在查询计划缓存中的计划。

查找正在等待的查询

从 SQL Server 2017 (14.x) 和 Azure SQL 数据库开始，查询存储中提供了一段时间内每个查询的等待统计信息。

在查询存储中，等待类型将合并到等待类别中。 sys.query_store_wait_stats (Transact-SQL) 中提供从等待类别到等待类型的映射。

在 SQL Server Management Studio v18 或更高版本中，选择“查询等待统计信息”以打开“查询等待统计信息”窗格。 “查询等待统计信息”窗格显示包含查询存储中排在前面的等待类别的条形图。使用顶部的下拉列表选择等待时间的聚合条件：平均值、最大值、最小值、标准偏差和总计（默认）。

通过选择条形图和所选等待类别展示的详细信息视图，选择等待类别。这个新的条形图包含对该等待类别有贡献的查询。

使用顶部的下拉列表框，根据各种等待时间条件为所选等待类别筛选查询：平均值、最大值、最小值、标准偏差和总计（默认）。选择某个计划以查看图形查询计划。可使用按钮来查看源查询，强制执行和取消强制执行某一查询计划，以及刷新显示内容。

等待类别可将不同等待类型按性质合并为类似的桶。不同的等待类别需要不同的后续分析才能解决此问题，但相同类别的等待类型可引起非常相似的故障排除体验，并假定基于等待的受影响的查询会成为用于成功完成大部分此类调查所缺少的部分。

下面的示例介绍如何在查询存储中引入等待类别前后更深入了解工作负荷：

曾经的体验	新的体验	操作
每个数据库的高 RESOURCE_SEMAPHORE 等待	特定查询在查询存储中的高内存等待	在查询存储中查找消耗内存最多的查询。这些查询可能会延迟受影响查询的进度。请考虑对这些查询或受影响的查询使用 MAX_GRANT_PERCENT 查询提示。
每个数据库的高 LCK_M_X 等待	特定查询在查询存储中的高锁定等待	检查受影响查询的查询文本，并确定目标实体。在查询存储中查找修改同一实体的其他查询，该实体频繁执行和/或具有较高持续时间。确定这些查询后，请考虑更改应用程序逻辑以提高并发性，或使用限制较少的隔离级别。
每个数据库的高 PAGEIOLATCH_SH 等待	特定查询在查询存储中的高缓冲 IO 等待	在查询存储中查找具有大量物理读取的查询。如果它们与含较高 IO 等待的查询匹配，执行执行搜索而不是扫描时，请考虑引入关于基础实体的索引，以便减少查询的 IO 开销。
每个数据库的高 SOS_SCHEDULER_YIELD 等待	特定查询在查询存储中的高 CPU 等待	查找查询存储中前几个使用 CPU 最多的查询。其中，请确定其高 CPU 趋势与受影响查询的高 CPU 等待关联的查询。重点优化这些查询 - 可能存在计划回归，或缺失的索引。

配置选项

有关配置查询存储参数的可用选项，请参阅 ALTER DATABASE SET 选项 (Transact-SQL)。

查询 sys.database_query_store_options 视图以确定查询存储的当前选项。有关值的详细信息，请参阅 sys.database_query_store_options。

有关使用 Transact-SQL 语句来设置配置选项的示例，请参阅选项管理。

备注

对于 Azure Synapse Analytics，可以像其他平台一样启用查询存储，但不支持其他配置选项。

查询存储维护

本文扩展了有关查询存储维护和管理的最佳做法和建议：管理查询存储的最佳做法。

性能审核和疑难解答

有关深入了解如何使用查询存储来优化性能的详细信息，请参阅使用查询存储优化性能。

其他性能主题：

Query Store 使用方案

更改数据库兼容性级别和使用查询存储

从 SQL Server 2016 (13.x) 及更高版本，某些更改仅在数据库兼容级别更改后才会启用。执行此操作的原因如下：

由于升级是单向操作（不可能降级文件格式），将新功能的启用分离为数据库内的单独操作有一定作用。可以将一项设置还原到之前的数据库兼容性级别。新的模式可以减少中断期间必然发生的事件的数量。
更改查询处理器可能会产生复杂的影响。即使对系统进行的是“较好的”更改（对大多数工作负荷而言可能是非常好的更改），也可能对其他工作负荷的重要查询造成不可接受的回归。通过从升级过程中分离此逻辑，查询存储等功能可在生产服务器中快速缓解计划选择回归或甚至完全将其规避。

附加或还原数据库时以及就地升级后，SQL Server 2017 (14.x) 应出现以下行为：

如果升级前用户数据库的兼容级别为 100 或更高，升级后将保持相应级别。
如果升级前用户数据库的兼容级别为 90，则在升级后的数据库中，兼容级别将设置为 100，该级别为 SQL Server 2017 (14.x) 支持的最低兼容级别。
升级后，tempdb、model、msdb 和 Resource 数据库的兼容性级别将设置为当前兼容性级别。
master 系统数据库保留它在升级之前的兼容级别。

用于启用新查询处理器功能的升级过程与产品的发布后服务模式相关。这些修补程序中的一部分发布在跟踪标志 4199 下。需要修补程序的客户可以选择加入这些修补程序而不会导致其他客户的意外回归。查询处理器修补程序的发布后服务模式记录于此处。从 SQL Server 2016 (13.x) 开始，转换到新的兼容性级别意味着不再需要跟踪标志 4199，因为在最新的兼容性级别中，这些修补程序现在默认启用。因此，作为升级过程的一部分，验证升级过程完成后未启用 4199 是很重要的。

备注

仍需要跟踪标志 4199 才能启用 RTM 之后发布的任何适用的新查询处理器修补程序。

查询存储使用方案中的“在升级到新版 SQL Server 期间保持性能稳定”部分中介绍了将查询处理器升级到最新版本的建议工作流，如下所示。

自 SQL Server Management Studio v18 起，用户可借助查询优化助手按指导操作建议的工作流。有关详细信息，请参阅[使用查询优化助手升级

数据库。

使用查询存储监视工作负载的最佳做法

本文概述使用 SQL Server 查询存储处理工作负载的最佳做法。

若要详细了解如何使用查询存储进行配置和管理，请参阅使用查询存储监视性能。
如需详细了解如何使用查询存储发现可操作信息并优化性能，请参阅使用查询存储优化性能。
有关在 Azure SQL 数据库中运行查询存储的信息，请参阅在 Azure SQL 数据库中运行查询存储。
在 Azure Synapse Analytics 中，默认情况下，不会为专用 SQL 池启用查询存储，但可以启用。不支持查询存储的其他配置选项。有关详细信息，请参阅 Azure Synapse Analytics 中的历史查询存储和分析。

使用最新版 SQL Server Management Studio

SQL Server Management Studio 提供了一组用户界面，旨在配置查询存储和使用收集的工作负载数据。下载 SQL Server Management Studio 的最新版本。

有关如何使用查询存储进行故障排除的简要说明，请参阅Query Store Azure blogs。

在 Azure SQL 数据库中使用 Query Performance Insight

如果在 Azure SQL 数据库中运行查询存储，则可使用 Query Performance Insight 来分析一定时段内的资源消耗情况。虽然可以使用 Management Studio 和 Azure Data Studio 来获取所有查询的详细资源消耗情况（例如 CPU、内存和 I/O），但使用 Query Performance Insight 可以快速且有效地确定查询对数据库总体 DTU 消耗情况的影响。有关详细信息，请参阅 Azure SQL Database Query Performance Insight（Azure SQL 数据库的 Query Performance Insight）。

将查询存储与弹性池数据库配合使用

可以毫无顾忌地在所有数据库中使用 Query Store，甚至是在密集打包的 Azure SQL 数据库弹性池中。之前与资源过度使用（为弹性池中的大量数据库启用了查询存储时可能会遇到这种情况）相关的所有问题都已得到了解决。

开始进行查询性能故障排除

查询存储工作流的故障排除很简单，如下图所示：

按上一节的说明通过 Management Studio 来启用查询存储，或者执行以下 Transact-SQL 语句：

SQL

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

1	ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

查询存储收集能够准确代表工作负载的数据集需要一定的时间。通常情况下，即使是很复杂的工作负荷，一天的时间也足够了。但是，在启用此功能后，就可以立即开始浏览数据并确定需要注意的查询。转到 Management Studio 的对象资源管理器中数据库节点下的查询存储子文件夹，然后打开特定方案的故障排除视图。

Management Studio Query Store 视图在操作时使用一组执行度量值，每个度量值都表示为下述任意统计函数：

展开表

SQL Server 版本	执行度量值	统计函数
SQL Server 2016 (13.x)	CPU 时间、持续时间、执行计数、逻辑读取次数、逻辑写入次数、内存消耗、物理读取次数、CLR 时间、并行度 (DOP) 和行计数	平均值、最大值、最小值、标准偏差、总数
SQL Server 2017 (14.x)	CPU 时间、持续时间、执行计数、逻辑读取次数、逻辑写入次数、内存消耗、物理读取次数、CLR 时间、并行度、行计数、日志内存、TempDB 内存和等待时间	平均值、最大值、最小值、标准偏差、总数

下图显示了如何查找 Query Store 视图：

下表说明了何时使用每个 Query Store 视图：

展开表

SQL Server Management Studio	方案
回归查询	查明哪些查询的执行度量值最近进行了回归（例如，变得更糟）。使用此视图将应用程序中观察到的性能问题与需要进行修复或改进的实际查询关联起来。
总体资源消耗	针对任意执行度量值分析数据库的总资源消耗量。使用此视图可以确定资源模式（白天工作负荷与夜间工作负荷的比较），并优化数据库的总体消耗。
资源使用排名靠前的查询	选择所关注的执行度量值，确定在指定的时间间隔内具有最极端值的查询。此视图可以帮助你关注最相关的查询，这些查询对数据库资源消耗的影响最大。
具有强制计划的查询	使用查询存储列出以前的强制计划。使用此视图快速访问当前的所有强制计划。
变化程度高的查询	分析执行变化程度较高的查询，此类变化可涉及任何可用的维度，例如所需时间间隔内的持续时间、CPU 时间、IO 和内存使用情况。使用此视图可以标识性能有很大差异且可能会影响用户跨应用程序体验的查询。
查询等待统计信息	分析数据库中最活跃的等待类别和对所选等待类别贡献最大的查询。使用此视图分析等待统计信息并识别可能在应用程序中影响用户体验的查询。适用于：从 SQL Server Management Studio v18.0 和 SQL Server 2017 (14.x) 开始。
跟踪的查询	实时跟踪最重要查询的执行情况。通常情况下，使用此视图是因为你计划强制执行相关查询，因此需确保查询性能的稳定性。

提示

如需详细了解如何使用 Management Studio 来确定资源使用排名靠前的查询并修复那些因计划选择变化而导致回归的查询，请参阅 Query Store Azure Blogs。

如果确定某个查询的性能不够理想，则可根据问题性质进行操作。

如果所执行的查询具有多个计划，而最后一个计划明显不如前面的计划，则可通过计划强制机制来强制使用最佳计划。 SQL Server 尝试强制实施优化器中的计划。如果计划强制实施失败，将触发 XEvent，并指示优化器正常优化。
备注
前面的图形针对特定的查询计划会显示不同的形状，以下是可能出现的每种形状的对应含义：
展开表
形状含义
圆形查询已完成，这意味着常规执行成功完成。
平方已取消，这意味着客户端发起的执行中止。
三角形失败，这意味着异常执行中止。
此外，形状大小反映指定时间间隔内的查询执行计数。如果执行次数较多，该形状会变大。
你可以认为，你的查询因为缺少索引而无法达到最佳执行效果。此信息显示在查询执行计划中。使用查询存储创建缺失的索引并检查查询性能。

形状	含义
圆形	查询已完成，这意味着常规执行成功完成。
平方	已取消，这意味着客户端发起的执行中止。
三角形	失败，这意味着异常执行中止。

如果你在 SQL 数据库上运行工作负载，可注册获取 SQL 数据库索引顾问，然后即可自动接收索引建议。

在某些情况下，如果你看到执行计划中估计的行数和实际的行数存在显著差异，则可强制执行统计信息的重新编译。
重写有问题的查询，例如可以充分利用查询参数化或实现更优化的逻辑。
提示

在 Azure SQL 数据库中，考虑使用查询存储提示功能，该功能可以在不更改代码的情况下对查询强制执行查询提示。有关详细信息和示例，请参阅查询存储提示。

确保查询存储持续收集查询数据

查询存储可在无提示的情况下更改操作模式。请定期监视查询存储的状态以确保查询存储正常运行，并采取相应措施，避免发生不必要的故障。执行以下查询，以便确定操作模式并查看最相关的参数：

SQL

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

USE [QueryStoreDB];

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,

max_storage_size_mb, readonly_reason, interval_length_minutes,

stale_query_threshold_days, size_based_cleanup_mode_desc,

query_capture_mode_desc

FROM sys.database_query_store_options;

actual_state_desc 和 desired_state_desc 之间存在差异，这表明自动更改了操作模式。最常见的更改是查询存储在无提示的情况下切换到只读模式。在极罕见的情况下，查询存储可能会因内部错误而导致处于错误状态。

当实际状态为只读时，可使用 readonly_reason 列来确定根本原因。通常情况下，你会发现，查询存储转换为只读模式是因为超出了大小配额。在这种情况下，readonly_reason 设置为 65536。有关其他原因，请参阅 sys.database_query_store_options (Transact-SQL)。

考虑执行以下步骤将 Query Store 切换为读写模式并激活数据收集功能：

使用 ALTER DATABASE 的 MAX_STORAGE_SIZE_MB 选项增大最大存储大小。
使用以下语句清理 Query Store 数据：
SQL
ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
1
ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;

在应用这两项或其中一项步骤时，可以执行以下语句，通过显式方式将操作模式改回为读写：

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。

打赏赞(1)

标签： SQL Server 整理自网络整理自官网 MSSQL 2016 查询存储

小麦苗

学习或考证，均可联系麦老师，请加微信db_bao或QQ646634621

发表回复取消回复

要发表评论，您必须先登录。

2024年 4月
一	二	三	四	五	六	日
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

嘿，我是小麦，需要帮助随时找我哦。

18509239930
个人微信
DB宝
个人邮箱
点击加入QQ群
个人微店
回到顶部

合 MSSQL 2016使用查询存储来监视性能

引言

使用查询存储来监视性能

简介

查询存储存储过程

目录视图

启用查询存储

使用 SQL Server Management Studio 中的“查询存储”页面

使用 Transact-SQL 语句

查询存储中的信息

次要副本的查询存储

使用回归查询功能

查找正在等待的查询

配置选项

相关视图、函数和过程

查询存储函数

查询存储目录视图

查询存储的存储过程

查询存储维护

性能审核和疑难解答

更改数据库兼容性级别和使用查询存储

使用查询存储监视工作负载的最佳做法

使用最新版 SQL Server Management Studio

在 Azure SQL 数据库中使用 Query Performance Insight

将查询存储与弹性池数据库配合使用

开始进行查询性能故障排除

确保查询存储持续收集查询数据

相关文章

您可能还喜欢...

发表回复取消回复

网站公告

网站寄语

本站其它工具

搜索本网站

标签云☁

网站日历

网站归档

网站分类

合 MSSQL 2016使用查询存储来监视性能

引言

使用查询存储来监视性能

简介

查询存储存储过程

目录视图

启用查询存储

使用 SQL Server Management Studio 中的“查询存储”页面

使用 Transact-SQL 语句

查询存储中的信息

次要副本的查询存储

使用回归查询功能

查找正在等待的查询

配置选项

相关视图、函数和过程

查询存储函数

查询存储目录视图

查询存储的存储过程

查询存储维护

性能审核和疑难解答

更改数据库兼容性级别和使用查询存储

使用查询存储监视工作负载的最佳做法

使用最新版 SQL Server Management Studio

在 Azure SQL 数据库中使用 Query Performance Insight

将查询存储与弹性池数据库配合使用

开始进行查询性能故障排除

确保查询存储持续收集查询数据

相关文章

您可能还喜欢...

MSSQL之单个SQL所能使用的CPU资源配置（并行配置）

所有数据库查询表和列的注释SQL汇总（Oracle、MySQL、PostgreSQL、GreenPlum、SQL Server）

MSSQL数据库连接工具之Azure Data Studio介绍

发表回复 取消回复

网站公告

网站寄语

本站其它工具

搜索本网站

标签云☁

网站日历

网站归档

网站分类

发表回复取消回复