标签: execution-plan

我有以下查询向我显示了 sql server 中缓存的内容：

SELECT cp.objtype AS ObjectType,
OBJECT_NAME(st.objectid,st.dbid) AS ObjectName,
cp.usecounts AS ExecutionCount,
st.TEXT AS QueryText,
qp.query_plan AS QueryPlan
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) AS qp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS st
WHERE 1=1
  --AND OBJECT_NAME(st.objectid,st.dbid) = 'YourObjectName'
  AND query_plan IS NOT NULL
ORDER BY ExecutionCount DESC

有没有办法可以查询 queryPlan 字段以查找丢失的索引？

我正在探索计划指南主题。听起来很简单，就我们通过文档中的示例而言。

问题是我找不到任何工作示例（我也没有设法自己弄清楚）来为存储过程或过程中的语句设置固定计划。

我已经阅读了很多博客文章，但它们都只是从 microsoft docs 复制/粘贴示例。

有人更有创意/经验丰富吗？

我遇到了一个很奇怪的问题。我正在运行相同的脚本来生成数据并稍后在较旧的 2008R2 实例上进行一些匹配。最后一个查询（一个UPDATE ) 执行单个表扫描并返回所有 250.000 行，而在较新的 2017 实例上，该表是并行扫描的，4 个线程中的每一个都读取 250.000 行，并返回 100 万“实际读取行”。

我在 2017 年的实例中将兼容模式更改为 2008 年，实际值保持不变，为 1.000.000。

为什么会发生这种情况是否有任何正当理由，或者这似乎应该是一个 Connect 项目？

计划包含相同的运算符，但其中一个执行并行扫描，而不是将 250.000 行拆分为 4 个线程中的每一个（并且每个线程仅读取 62.500 行）所有线程读取 250k，每个 *4 = 1.000.000

两个执行计划都可以在 pastetheplan 找到：

• 2017版在这里
• 2008R2 版本在这里

此外，我正在运行的完整脚本可以在下面找到：

create table #targets (id int identity(1,1), start_point int, end_point int, refference_type_id int, bla1 int, bla2 int, bla3 int, bla4 int, bla5 int, bla6 int, bla7 int, bla8 int, bla9 bit, assignedTouch varchar(10));

;with cte as (
    select
        1 …

我面临 SQL Server 生成非最佳执行计划的问题：嵌套循环连接并寻找维度表并对其执行 2M 读取。

排序操作估计是 100 行而不是 450 K 行，可能会影响计划选择：

NestedLoop：https ://www.brentozar.com/pastetheplan/ ? id = B110MZ2Pm或 NestedLoop 计划

这是在测试数据库中。我们有一个具有相同架构和几乎相同数据的附加数据库。

运行完全相同的查询（均来自 SSMS）使用哈希联接和维度表扫描（32K 读取）生成不同的计划：

HashJoin：https ://www.brentozar.com/pastetheplan/ ? id = r1Jm7b2D7或 哈希计划

我需要帮助来理解和解决问题。

我可以通过提示 Hash Joint 来解决这个问题，但是同一实例上的 2 个相似的 DB 生成不同的计划没有任何意义。

更新 #1：我发现估计的成本是不同的所以当 SQL Server 并行执行时，它会选择一个散列连接。

用单线程会嵌套循环。

更新 #2：在从同一个表中进行 SELECT 时发生了同样的问题。取决于列数（估计成本）。当我减少列数时，执行计划陷入嵌套循环并寻找维度表。

我在 Azure (DS11) 上的 VM 上安装了 SQL Server 2019。我试图在这里使用这篇文章来说明自适应查询处理。问题是，当我 CTRL+L在 SQL Server Management Studio 中查看执行计划时，我看不到那里的内存授予。

我现在的问题是，如果我以管理员身份登录，是否只能看到内存授予？还是 SQL Server 2019 的查询引擎与 SQL Server 2017 完全不同？

这是我在SQL Server 2008 R2, 2012,上测试过的复制品2016。

第二个和第三个查询确实使用了RowCount Spool，为什么第一个没有？

create table dbo.t (id int identity primary key, v int);
--create statistics ST_t__v on dbo.t(v) with norecompute;

insert into dbo.t (v)
select top (10000) rand(checksum(newid())) * 5
from master.dbo.spt_values a cross join
     master.dbo.spt_values b;
go

declare @v int;

set statistics xml, io on;
select @v = v from dbo.t where exists(select 1 from dbo.t where v = 4);
select @v = v from dbo.t where exists(select …

我有一个DELETE针对带有全文索引列的表运行的语句，cascade启用了一些外键。它看起来像这样：

DELETE FROM dbo.STUDENTS WHERE STUDENTID=@STUDENTID

有时会编译一个计划，其中包括对所有索引操作的非常高的行估计，因此DELETE需要很长时间并导致锁定。

我试图迫使QueryStore一个很好的计划，但是这并不实际工作，表现出last forced plan failure description的NO_PLAN。

我已确保没有可能使计划无效的架构更改。

查看执行计划，我看到这DELETE涉及到一个包含 FT 索引的系统表的连接：

加入 FT 索引是否意味着不支持计划强制？

在下面的例子中，结果Index Spool已经排序，为什么我们Top N Sort这里有而不是简单的Top？

use tempdb;
go

create table dbo.t1 (id int identity primary key, v int);
create table dbo.t2 (id int identity primary key, v int);

insert into dbo.t1
(v)
select top (1000)
row_number() over (order by 1/0)
from
master.dbo.spt_values a cross join
master.dbo.spt_values b;

insert into dbo.t2
(v)
select top (10000)
row_number() over (order by 1/0) + 10000
from
master.dbo.spt_values a cross join
master.dbo.spt_values b;

set statistics xml, io on;

select
sum(a.v …

使用 PostgreSQL 11，我有下表，大约有 4.5 亿行：

postgres=> \d+ sales
                                                             Table "public.sales"
              Column               |            Type             |             Modifiers              | Storage  | Stats target | Description
-----------------------------------+-----------------------------+------------------------------------+----------+--------------+-------------
 created_terminal_id               | integer                     | not null                           | plain    |              |
 company_id                        | integer                     | not null                           | plain    |              |
 customer_id                       | integer                     |                                    | plain    |              |
 sale_no                           | character varying(20)       | not null                           | extended |              |
 sale_type                         | smallint                    | not null                           | plain    |              |
 source_type                       | smallint                    | not null                           | plain …

我有一个具有复杂逻辑和三个深度级别（嵌套视图）的视图。由于复杂，我无法粘贴执行计划。

由于视图的目的是向数据分析师提供一些业务分析，而他们正在开发报告时，他们会通过执行选择（前 N 个）查询来检查视图样本。

视图中的这个（前 N 个）查询执行得非常糟糕，因为优化器正在为此视图选择不同的执行计划（afaik CQScanTopSortNew）

我尝试对顶部 (N) 用例进行一些优化，例如使用哈希连接，但这会破坏非顶部 (n) 用例。

非顶级 (n) 表现良好。我想知道如何防止优化器在具有 top (n) 子句时选择不同的执行计划，而不会显着改变视图的结构或功能。

例如，如果我在视图中添加一个 select distinct ，优化器总是会选择正确的计划，但视图的功能会发生变化。