问题标签 [sql-execution-plan]

我在以 2000 兼容模式运行的 SQL 2005 服务器上有一个充满数据的表ItemValue，它看起来像（它是一个用户定义的值表）：

FieldID来自ItemField表：

因为我不能在 2000 模式下 PIVOT，所以我们被困在使用 CASE 和 GROUP BY 构建一个丑陋的查询来获取数据以查看它应该如何用于某些遗留应用程序，即：

你可以看到我们只需要这个表来显示直到第 51 个 UDF 的值。这是查询：

当FieldNumber约束 <= 51 时，执行计划类似于：

SELECT <== Computer Scalar <== Stream Aggregate <== Sort (Cost: 70%) <== Hash Match <== (Clustered Index Seek && Table Scan)

而且速度很快！我可以在大约一秒钟内拉回 100,000+ 条记录，这符合我们的需求。

但是，如果我们有更多的 UDF，并且我将约束更改为66以上的任何值（是的，我对它们进行了逐个测试），或者如果我完全删除它，我会丢失执行计划中的排序，它会被一大堆替换并行块收集、重新分区和分发流，整个过程很慢（即使只有 1 条记录也需要 30 秒）。

FieldNumber有一个聚集的唯一索引，并且是ItemField表中具有ID列（非聚集索引）的复合主键的一部分。ItemValue表的ID和ItemNumber列构成一个 PK， ItemNumber列上有一个额外的非聚集索引。

这背后的原因是什么？为什么更改我的简单整数约束会更改整个执行计划？

如果你能做到……你会做些什么不同的事情？从现在开始有几个月的 SQL 升级计划，但我需要在此之前解决这个问题。

我正在尝试调整一些存储过程并对索引有疑问。我使用了调优顾问，他们推荐了两个索引，都用于同一个表。问题是一个索引用于一列，另一个索引用于多列，其中它包含与第一列相同的列。我的问题是为什么和有什么区别？

我正在尝试从 Oracle SQL Developer 2.1.0.63 导出解释计划的副本

我得到的只是一个名为我指定的html文件，然后是同一目录中新创建的文件夹，名为“images”，它是空的。

我对 (cough)tabular(cough) HTML 输出进行了测试，发现指定了六张图像，但我认为有 CSS（未指定内联样式，但未导入 CSS）和 Javascript（扩展/收缩区域）我也错过了。

我尝试在谷歌上搜索最独特的图像名称，但我找不到任何其他有此问题的资源。

是否有在线位置我可以获取这些图像/CSS/Javascript，或者这是一个错误并且在某处有修复或者我只是一个菜鸟？

我正在使用 SQL Developer 的机器具有完全的管理员权限，所以它不应该是缺乏创建权限的问题，尤其是在我自己的桌面/我的文档中，除非图像存储在另一个地方。我正在搜索我的硬盘现在，看看我是否可以在任何地方找到它们......

我有一个非常简单的查询，它给了我意想不到的结果。欢迎提供有关在何处进行故障排除的提示。

简化，查询是：

这给了我一个查询成本：963。但是，如果我将查询更改为：

尽管它（应该）返回相同的数据，但估计成本会飙升至17688。这里的问题可能出在哪里？谢谢。

编辑：查询计划说索引ObsHead.Name用于范围扫描，而 ObsHead 上的表访问成本仅为 4。还有另一个索引Obs.hdId用于范围扫描，成本为 94：它是表之间的嵌套循环连接最高可达 17K。

我有一个动态创建的 LINQ to SQL 查询。有趣的是，当我在 SQL Management Studio 中运行它时，速度非常快。当我从 L2S 运行它时，它会在一段时间后变得非常缓慢。

这可能是因为查询计划/执行计划。当我重新启动 SQL Server 时，L2S 查询也再次快如闪电。

现在使用 T-SQL，您可以使用 WITH RECOMPILE。但是如何使用 L2S 做到这一点？

我希望能够将 SQL Server 查询计划从 XML 转换为图像。理想情况下是矢量格式，但位图可以。

有没有开源库可以做到这一点？或者我可以使用 SQL Server Management Studio DLL 之一吗？

谢谢。

我一直在努力将我们的一些数据从 Microsoft SQL Server 2000 迁移到 2008。在常见的问题和诸如此类的情况下，我遇到了一些奇怪的事情。下面链接的是一个 SQL 查询，它在 2000 下返回非常快，但在 2008 下需要 20 分钟。我已经阅读了很多关于升级 SQL 服务器的内容，并在得出结论之前走上了检查索引、统计信息等的常用路径在 WHERE 子句中找到的以下语句会导致该语句后面的步骤的执行计划发生巨大变化：

SQL 语句和执行计划链接如下。

一位同事能够使用 CASE 语句重写 WHERE 子句的一部分，这似乎“欺骗”了优化器使用更好的执行计划。带有 CASE 语句的版本也包含在链接档案中。

我想看看是否有人解释了为什么会发生这种情况，以及是否有比使用 CASE 语句更优雅的解决方案。虽然我们可以解决这个特定问题，但我希望对正在发生的事情有更广泛的了解，以确保迁移的其余部分尽可能轻松。

包含 SQL 语句和 XML 执行计划的 Zip 文件

提前致谢！

我有一个查询在 2 个数据集之间返回的时间相差很大。对于一组（数据库 A），它会在几秒钟内返回，对于另一组（数据库 B）......好吧，我还没有等待足够长的时间，但是超过 10 分钟。我已将这两个数据库都转储到我的本地机器上，在那里我可以重现运行 MySQL 5.1.37 的问题。

奇怪的是，数据库 B 比数据库 A 小。

重现该问题的查询的精简版本是：

在约 2 秒内返回的第一个数据库 (A) 的 EXPLAIN 查询计划是：

在 >600 秒内返回的第二个数据库 (B) 的 EXPLAIN 查询计划是：

当数据库 B 运行时，我可以查看 MySQL 管理员，并且状态无限期地保持在“复制到 tmp 表”。数据库 A 也有这种状态，但只有一秒钟左右。

这些数据库之间的表结构、索引、键等没有区别（我已经展示了创建表并对其进行了比较）。

桌子的大小是：

需要注意的几点：

• 删除 WHERE 子句使查询返回 < 1 秒。
• 删除 GROUP BY 会使查询返回 < 1 秒。
• 删除 ev5、ev4、ev3 等会使每删除一个查询变得更快。

AJ 回答后更新： - 数据库 B（最大值 = 800002752）上的 ship_id 的大小明显大于数据库 A（最大值 = 3489）。鉴于这些是 InnoDB 表，是否会更改任何缓冲区以帮助处理这种大小的键？对此的进一步更新：我减小了键的大小并重新分析，但性能仍然没有变化。

更新EVENT_TABLE 的描述：

请注意，这在两个数据库中是相同的

为了更好地衡量 SHOW CREATE TABLE EVENT_TABLE：

数据库之间唯一不同的是自动增量值

谁能建议如何解决这个问题？我错过了什么？

Michael Holzmann 提问后更新 这是基于他更新的 STRAIGHT_JOIN 查询的新查询计划。请注意，数据库 B 具有“使用临时；使用文件排序”，而现在数据库 A 没有。这可能是由于长键或类似原因造成的吗？

数据库 A

数据库 B

更新这绝对是数据相关的。我从数据库 A 中转储数据并将其加载到数据库 B 中：

和

然后数据库 B 查询运行得很快——即。与数据库 A 一样快。关于如何诊断数据可能有什么问题的任何想法？

更新@newtover：来自数据库A：

来自数据库 B（坏的）

节目为 po_shipment 创建：

更新@chris_I 如果我通过删除除 EVENT_TABLE 之外的所有其他连接来删除查询，我会得到相同的性能（即糟糕）

更新@Marcus Adams：查询您已删除内部连接的计划：

来自数据库 A 的查询计划（0.35s 内响应）

来自数据库 B 的查询计划（没有及时响应泡茶所需的时间）

我试图了解 SQL Server 执行计划中的物理运算符。这个页面很有帮助：

http://technet.microsoft.com/en-us/library/ms191158.aspx

SSMS 2008 显示了一些在 SSMS 2005 中未显示的物理运算符属性：Estimated Number of Executions和Number of Executions。但这些实际上是什么意思，它们与重新绑定和倒带有什么关系？

Estimated Number of Executions特别有趣，因为它似乎没有存储在 XML 中。那么它是如何计算的呢？似乎等于Estimated Rebinds + Estimated Rewinds + 1.0。但如果是这样，为什么Number of Executions不等于Actual Rebinds + Actual Rewinds + 1？

谢谢。

在另一个问题中，我试图研究如何控制 SQL Server 的查询计划缓存：

https://stackoverflow.com/questions/2593749/is-there-an-equivalent-of-optionrecompile-or-with-recompile-for-an-entire-c

...我通过这篇文章找到了跟踪标志 253：

http://www.sqlservercentral.com/Forums/Topic837613-146-1.aspx

文章是正确的，如果我运行 DBCC TRACEON(253) 然后进行一些查询，我可以手动检查查询计划缓存并查看计划尚未插入。如果我运行 DBCC TRACEOFF(253)，查询计划将正常缓存。

所以我的问题是......这个标志还有什么作用？有人知道官方的说法吗？