标签: execution-plan

在标准 SQL 中，union all不保证a 的结果按任何顺序排列。所以，像这样：

select 'A' as c union all select 'B'

可以以任何顺序返回两行（尽管实际上在我知道的任何数据库上，'A' 都会出现在 'B' 之前）。

在 SQL Server 中，这变成了使用“串联”物理操作的执行计划。

我可以很容易地想象连接操作会扫描它的输入，返回任何有可用记录的输入。但是，我在网络上发现了以下声明（此处）：

Query Processor 将按照操作符出现在计划中的顺序执行这个计划，第一个是最上面的，最后一个是最后一个。

问题：这在实践中是真的吗？这能保证是真的吗？

我还没有在 Microsoft 文档中找到任何参考资料，说明按顺序扫描输入，从第一个到最后一个。另一方面，每当我尝试运行它时，结果表明输入确实是按顺序处理的。

有没有办法让引擎一次处理多个输入？我的测试（使用比常量更复杂的表达式）是在支持并行的 8 核机器上进行的，并且大多数查询确实利用了并行性。

DBCC FREEPROCCACHE在 Azure SQL DB 中不起作用。我还能如何强制计划以一种不会伤害生产系统的方式将自己踢出缓存（即我不能随意更改表）？这是专门为 Entity Framework 创建的 SQL，所以这些不是自我管理的存储过程 - 它是有效的动态 SQL。

（来源是糟糕的索引 -> 糟糕的统计数据等。这一切都已解决，但糟糕的计划不会消失。）

更新： 当他首先到达那里时，我选择了@mrdenny 的解决方案。然而，我成功地使用@Aaron Bertrand 的脚本来执行这项工作。感谢大家的帮助！！

您必须原谅我的天真，因为我不是 DBA，但我的理解是，随着时间的推移，必须重新编译数据库更改和存储过程的统计信息，以使查询计划与最新的统计信息保持同步。

假设我在我的数据库中的存储过程，在对重新编译的最新统计一些固定的间隔，是什么在衬里的存储过程的代码，并在包裹它的含义sp_executesql的语句？我是否会丢失过去作为过程重新编译的一部分发生的查询计划的刷新？

如果在进行此更改之前我需要考虑其他任何事项（权限除外），那么我将不胜感激。

我在 MSDN 上读到这个：

SQL Server 查询优化器将新的 Transact-SQL 字符串与现有执行计划相匹配的能力受到字符串文本中不断变化的参数值的阻碍，尤其是在复杂的 Transact-SQL 语句中。

因此，假设我尝试内联和换行的存储过程sp_executesql确实包含一些参数，这是否是说虽然我的执行计划已缓存，但我让 SQL Server 更难找到和重用它？

给定以下常量：

• 具有相同结构（表、索引等）的相同数据库
• 相同的数据
• 相同的 SQL Server 和硬件配置
• 相同的统计
• 客户端中相同的 SET 选项
• 相同的 SQL Server 版本
• 相同的跟踪标志

给定这些常量，SQL Server 是否总是为给定的查询生成相同的计划？

如果没有，是否还有其他考虑？是否还需要考虑不确定性因素？

大家好 我的 PostgreSQL 数据库查询有问题，想知道是否有人可以提供帮助。在某些情况下，我的查询似乎忽略了我创建的用于连接两个表data和data_area. 发生这种情况时，它使用顺序扫描并导致查询速度慢得多。

顺序扫描（~5 分钟）

Unique  (cost=15368261.82..15369053.96 rows=200 width=1942) (actual time=301266.832..301346.936 rows=153812 loops=1)
   CTE data
     ->  Bitmap Heap Scan on data  (cost=6086.77..610089.54 rows=321976 width=297) (actual time=26.286..197.625 rows=335130 loops=1)
           Recheck Cond: (datasetid = 1)
           Filter: ((readingdatetime >= '1920-01-01 00:00:00'::timestamp without time zone) AND (readingdatetime <= '2013-03-11 00:00:00'::timestamp without time zone) AND (depth >= 0::double precision) AND (depth <= 99999::double precision))
           ->  Bitmap Index Scan on data_datasetid_index  (cost=0.00..6006.27 rows=324789 width=0) (actual time=25.462..25.462 rows=335130 loops=1)
                 Index Cond: …

根据这个答案，除非在用于限制的列上建立索引，否则查询将不会从索引中受益。

我有这个定义：

CREATE TABLE [dbo].[JobItems] (
    [ItemId]             UNIQUEIDENTIFIER NOT NULL,
    [ItemState]          INT              NOT NULL,
    [ItemPriority]       INT NOT NULL,
    [CreationTime]       DATETIME         NULL DEFAULT GETUTCDATE(),
    [LastAccessTime]     DATETIME         NULL DEFAULT GETUTCDATE(),
     -- other columns
 );

 CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
    ON [dbo].[JobItems]([ItemId] ASC);
 GO

CREATE INDEX [GetItemToProcessIndex]
    ON [dbo].[JobItems]([ItemState], [ItemPriority], [CreationTime])
    INCLUDE (LastAccessTime);
GO

和这个查询：

UPDATE TOP (150) JobItems 
SET ItemState = 17 
WHERE 
    ItemState IN (3, 9, 10)
    AND LastAccessTime < DATEADD (day, -2, GETUTCDATE()) 
    AND CreationTime < DATEADD (day, …

我一直在 sql 错误日志上发现奇怪的错误消息：

Bocss：每小时都会发生同样的僵局——需要调查

根据以下示例，其他 SPID 的错误日志中还列出了许多重新编译：

2015年9月4日14：30：10，spid64，未知，用于SQLHANDLE 0x0200000059631A288882589E0C54B76404CAE1B97E08D3680000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000000000000000000000检测到可能无限的重新编译起始偏移1038结束偏移2600的最后一个重新编译原因是2. 2015年9月4日14时三十分十秒，spid150，未知，是为SQLHANDLE 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A0000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000起始偏移量998检测到的一个可能的无穷的重新编译结束偏移2520。最后重新编译原因是2. 2015年9月4日14：30：09，spid67，未知检测到可能无限的重新编译为SQLHANDLE 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000起始偏移1064结束偏移2652是2. 2015年9月4日14最后重新编译原因：30：09，spid163，未知，是为SQLHANDLE 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle探测到一个可能无限的重新编译0x06000400E7C7BF0EF0EB68A52C00000001000000000000000000000000000000000000000000000000000000开始偏移量1028结束偏移2580的最后一个重新编译的原因是2。

是什么导致了这种情况？

看起来我没有缓存中的计划了。

按照这篇文章的建议 http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx

然后作为安全措施禁用全文目录，这没有区别，所以我完全回滚了更改（删除了新对象等）。这也没什么区别，最后似乎唯一阻止它的是重新启动 SQL 实例，这立即解决了问题。

这也解决了我的问题，但是，我仍然要找出造成这种混乱的原因是什么？

我主要是使用实体框架 ORM 的 .NET 开发人员。但是，因为我不想在使用 ORM时失败，所以我试图了解数据层（数据库）中发生了什么。基本上，在开发过程中，我启动分析器并检查代码的某些部分根据查询生成了什么。

如果我发现一些非常复杂的事情（ORM 甚至可以从相当简单的 LINQ 语句中生成糟糕的查询，如果编写不仔细）和/或繁重（持续时间、CPU、页面读取），我会将它放入 SSMS 并检查其执行计划。

它适用于我的数据库知识水平。但是， BULK INSERT 似乎是一种特殊的生物，因为它似乎不会产生 SHOWPLAN。

我将尝试说明一个非常简单的例子：

表定义

CREATE TABLE dbo.ImportingSystemFileLoadInfo
(
    ImportingSystemFileLoadInfoId INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_ImportingSystemFileLoadInfo PRIMARY KEY CLUSTERED,
    EnvironmentId INT NOT NULL CONSTRAINT FK_ImportingSystemFileLoadInfo REFERENCES dbo.Environment,
    ImportingSystemId INT NOT NULL CONSTRAINT FK_ImportingSystemFileLoadInfo_ImportingSystem REFERENCES dbo.ImportingSystem,
    FileName NVARCHAR(64) NOT NULL,
FileImportTime DATETIME2 NOT NULL,
    CONSTRAINT UQ_ImportingSystemImportInfo_EnvXIs_TableName UNIQUE (EnvironmentId, ImportingSystemId, FileName, FileImportTime)
)

注意：表上没有定义其他索引

批量插入 （我在探查器中捕获的内容，仅一批）

insert bulk [dbo].[ImportingSystemFileLoadInfo] ([EnvironmentId] …

我正在使用 SQL Server 2012 企业版。我遇到了一个 SQL 计划，它表现出一些我认为并不完全直观的行为。在执行大量并行索引扫描操作后，会发生并行（重新分区流）操作，但它会终止索引扫描 (Object10.Index2) 返回的行估计值，将估计值减少到 1。我已经进行了一些搜索，但是没有遇到任何可以解释这种行为的东西。查询非常简单，尽管每个表都包含数百万的记录。这是 DWH 加载过程的一部分，这个中间数据集在整个过程中被触及了几次，但我的问题特别与行估计有关。有人可以解释为什么在并行（重新分区流）运算符中准确的行估计值变为 1？还，

我已将完整计划发布到Paste the Plan。

这是有问题的操作：

包括计划树，以防添加更多上下文：

我能运行到的一些变化这个连接项目由保罗·怀特（进一步深入explination在自己的博客提交这里）？至少这是我发现的唯一一个似乎与我遇到的情况非常接近的东西，即使没有 TOP 运算符在起作用。

查询存储强制计划功能似乎没有执行该计划。

我知道Query Store - Forced 并不总是意味着 Forced；然而，我的计划可能不会发生微不足道的变化，但查询优化器可能会继续选择不正确的索引、循环选择等。

基本上：它不尊重我被迫的计划选择。我强迫了很多计划，但它根本行不通。

1. 当我查看sys.query_store_plan force_failure_count.
2. 扩展事件query_store_plan_forcing_failed不会产生任何结果。0 事件。

例如，在 20.09 强制执行的计划。只有 1 个编译碰巧使用了强制计划。

计划大相径庭，一个使用带有 INDEX 1 的 Hash Match join，另一个使用带有 INDEX 2 的 Loop Join。

版本：Microsoft SQL Server 2016 (SP1-GDR) (KB3210089) - 13.0.4202.2 (X64)

我在这里缺少什么？