标签: execution-plan

SentryOne Plan Explorer是否像宣传的那样工作，是否合法？有什么问题或需要担心的事情吗？

与 SSMS 对估计执行计划视图的噩梦相比，它似乎以颜色显示了热路径。

我担心的是 - 它是否恶意或以其他方式修改任何数据？

编辑：我刚刚听说过它，以前从未听说过这家公司。

我们的生产环境有这个问题。

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Windows NT 6.1（内部版本 7601：Service Pack 1）上的企业版（64 位）。

SQL Server 正在删除所有（几乎 100%）旧的执行计划，并在每天夜间（从晚上 11:00 到早上 8:00）重新创建它们。当“自动更新统计信息”处于禁用状态时，甚至会发生这种情况。在过去的 2-3 周内，我们已经开启了“自动更新统计信息”。但它仍在发生。

我们真的不知道是什么触发了这种重新生成计划，但我们确信我们不会手动进行。

唯一真正与计划重新生成时间一致的是我们的数据库维护工作：每日索引重组（碎片为 5-30% 时），以及每日索引重建（碎片超过 30% 时） ） 工作。通常这个日常维护工作只做重组（因为每天的索引碎片永远不会超过 30%）。

影响：

这些新创建的计划使一些 UDF 调用/查询调用（从 UI/网页调用）花费更长的时间（分钟而不是不到 1 秒），因此会话只会堆积起来，使 CPU 接近 90% .

当那些卡住的会话被强行删除（在 DB 端）时，问题就会消失，并且 1）当所有相应的执行计划被手动清除（对于查询）或 2）当 UDF 被更改（对于函数）时。从那一刻起，SQL 服务器创建的任何新计划都会在一天中完美运行，直到第二天早上最终出现相同的问题。此外，这种行为并不是 100% 一致的，我们并不是每天早上都能看到它。但是有一段时间我们已经连续 4-5 天看到它了。

问题发生在工作日的早晨，这似乎是更频繁地访问 UI/网页的时候。

有没有人知道是什么导致了这个问题以及如何解决这个问题？任何帮助将非常感激。

给定下表、唯一聚集索引和统计信息：

CREATE TABLE dbo.Banana
(
    pk integer NOT NULL, 
    c1 char(1) NOT NULL, 
    c2 char(1) NOT NULL
);

CREATE UNIQUE CLUSTERED INDEX pk ON dbo.Banana (pk);

CREATE STATISTICS c1 ON dbo.Banana (c1);
CREATE STATISTICS c2 ON dbo.Banana (c2);

INSERT dbo.Banana 
    (pk, c1, c2) 
VALUES 
    (1, 'A', 'W'), 
    (2, 'B', 'X'), 
    (3, 'C', 'Y'), 
    (4, 'D', 'Z');

-- Populate statistics
UPDATE STATISTICS dbo.Banana;

在任何更新之前，统计行修改计数器显然显示为零：

-- Show statistics modification counters
SELECT
    stats_name = S.[name], 
    DDSP.stats_id,
    DDSP.[rows],
    DDSP.modification_counter
FROM sys.stats AS S
CROSS …

我们最近升级了我们使用的一个应用程序，其中涉及修改数据库的架构。这些更改可能会迫使缓存的执行计划被丢弃。如果 SQL Server 被迫创建一堆新计划，这可能会降低用户体验。我想知道是否是这种情况。

所以，我的问题是，SQL Server 2008 是否存储缓存执行计划的创建日期？管理视图sys.dm_exec_cached_plans没有任何日期字段，所以我怀疑没有。

在标准 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 是否总是为给定的查询生成相同的计划？

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

我在AdventureWorks2012数据库中运行此查询：

SELECT 
    s.SalesOrderID,
    d.CarrierTrackingNumber,
    d.ProductID,
    d.OrderQty
FROM Sales.SalesOrderHeader s 
JOIN Sales.SalesOrderDetail d 
    ON s.SalesOrderID = d.SalesOrderID
WHERE s.CustomerID = 11077

如果我查看估计的执行计划，我会看到以下内容：

初始索引查找（右上角）使用 IX_SalesOrderHeader_CustomerID 索引并搜索文字 11077。它估计有 2.6192 行。

如果我使用DBCC SHOW_STATISTICS ('Sales.SalesOrderHeader', 'IX_SalesOrderHeader_CustomerID') WITH HISTOGRAM，则显示值 11077 介于两个采样键 11019 和 11091 之间。

11019 和 11091 之间不同行的平均数为 2.619718，或四舍五入为 2.61972，这是为索引查找显示的估计行的值。

我不明白的部分是针对 SalesOrderDetail 表的聚集索引查找的估计行数。

如果我运行DBCC SHOW_STATISTICS ('Sales.SalesOrderDetail', 'PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID')：

所以 SalesOrderID（我正在加入）的密度是 3.178134E-05。这意味着 1/3.178134E-05 (31465) 等于 SalesOrderDetail 表中唯一 SalesOrderID 值的数量。

如果 SalesOrderDetail 中有 31465 个唯一的 SalesOrderID，那么在均匀分布的情况下，每个 SalesOrderID 的平均行数为 121317（总行数）除以 31465。平均值为 3.85561

因此，如果估计要循环的行数是 …

查询执行计划默认不显示锁定详细信息，是否可以查看在查询执行期间获取的锁定以及类型？