问题标签 [sql-execution-plan]

情况如下：
我有一个带有 datetime 参数的表值函数，例如 tdf(p_date)，它过滤大约 200 万行，选择列 date 小于 p_date 的行，并计算其他列的一些聚合值。
它工作得很好，但如果 p_date 是一个自定义标量值函数（在我的例子中返回一天结束），执行计划就会改变，查询从 1 秒到 1 分钟执行时间。

概念证明表 - 1K 产品，2M 行：

内联表值函数：

标量值函数：

查询 1 - 工作得很好

执行计划结束：Stream Aggregate Cost 13% <--- Clustered Index Scan Cost 86%

查询 2 - 不太好

执行计划结束：Stream Aggregate Cost 4% <--- Filter Cost 12% <--- Clustered Index Scan Cost 86%

我们有一个查询在我们的生产系统上大约需要 5 秒，但在我们的镜像系统（尽可能与生产系统相同）和开发系统上需要不到 1 秒。

我们检查了查询计划，我们可以看到它们不同。同样从这些计划中，我们可以看到为什么一个比另一个花费更长的时间。数据、架构和服务器相似，存储过程相同。

我们知道如何通过重新安排连接和添加提示来修复它，但是目前如果我们不必对 SProc（文书工作）进行任何更改，这会更容易。我们也尝试过 sp_recompile。

什么可能导致两个查询计划之间的差异？

系统：Win2k3 Enterprise 上的 SQL 2005 SP2 Enterprise

更新：感谢您的回复，原来是统计数据。请参阅下面的摘要。

我有一个处理大量数据的存储过程（在这个例子中大约有 5m 行）。性能差异很大。我已经让这个过程在短短 15 分钟内运行，并且看到它运行了长达 4 小时。

为了维护，并且为了验证逻辑和处理是否正确，我们将 SP 分成几个部分：

1. TRUNCATE并填充一个工作表（索引），我们稍后可以使用自动化测试工具进行验证。

2. 将几个表连接在一起（包括其中一些工作表）以生成另一个工作表

重复 1 和/或 2，直到产生最终输出。

我担心的是这是一个单一的 SP，因此在第一次运行时会得到一个执行计划（甚至WITH RECOMPILE）。但当时，工作表（Work 模式中的永久表）是空的。

我担心，无论索引方案如何，执行计划都会很差。

我正在考虑拆分 SP 并从其中调用单独的 SP，以便在构建工作表中的数据后，它们可以利用重新评估的执行计划。我还看到了使用 EXEC 运行动态 SQL 的参考，显然也可能得到一个RECOMPILE。

我仍在尝试获得SHOWPLAN许可，所以我很盲目。

我正在尝试确定两个不同查询的相对性能，并有两种方法可供我使用：
1. 运行两者并为每个查询计时
2. 运行两者并从实际执行计划中获取“查询成本”

这是我为查询计时而运行的代码...

我得到的是以下内容：

执行时间的结果直接与查询成本的结果相矛盾，但我很难确定“查询成本”的实际含义。我最好的猜测是它是 Reads/Writes/CPU_Time/etc 的集合，所以我想我有几个问题：

1. 是否有明确的来源来解释该措施的含义？

2. 人们还使用哪些其他“查询性能”指标，它们的相对优点是什么？

需要注意的是，这是一个中型 SQL Server，在 MS Server 2003 Enterprise Edition 上运行 MS SQL Server 2005，具有多个处理器和 100 多个并发用户。

编辑：

经过一番麻烦后，我设法获得了对该 SQL Server 的 Profiler 访问权限，并且可以提供额外的信息（它支持与系统资源相关的查询成本，而不是执行时间本身......）

令人印象深刻的是，使用更多的 CPU 和更多的读取需要更少的时间 :)

经过大量工作，我终于得到了一个相当复杂的查询，可以非常顺利地工作并很快返回结果。

它在开发和测试中运行良好，但现在测试速度大大放缓。在开发中花费 0.06 秒并且在测试中大致相同的解释查询现在在测试中是 7 秒。

解释略有不同，我不确定为什么会这样 来自开发的解释

并且在测试中

即使查询完全相同，表的顺序也不同。这是导致减速的原因吗？如果是这样，我将如何解决它？开发是windows，测试是centOs。两者都运行相同版本的 mysql 5.0，就像我说的，测试运行完美，我没有对数据库进行任何结构更改。

我运行了 mysqlcheck，所有表都恢复正常。

我有一个参数化查询。根据参数值，最佳查询计划会有很大差异。麻烦在于：Oracle 将第一次查询调用的计划用于后续调用，导致性能不佳。我通过动态 SQL 处理它，但这种方式远非优雅。那么问题来了：有没有办法告诉Oracle必须重新计算查询计划？

我正在帮助维护一个程序，该程序本质上是一个用于大型复杂 MySQL 数据库的友好只读前端——该程序根据用户输入构建临时 SELECT 查询，将查询发送到数据库，获取结果，对它们进行后处理，并将它们很好地显示给用户。

我想为构造查询的预期性能添加某种形式的合理/启发式预测——有时用户无意中进行了不可避免地需要很长时间的查询（因为他们会返回巨大的结果集，或者因为他们'重新“违背”数据库索引的方式），我希望能够向用户显示一些“有点可靠”的信息/猜测查询需要多长时间。它不一定是完美的，只要它不会变得如此糟糕和频繁地与现实脱节，以至于导致用户学会无视它的“哭狼”效应；-) 基于此信息，用户可能决定去喝杯咖啡（如果估计是 5-10 分钟），去吃午饭（如果是 30-60 分钟），

我对 MySQL 的 EXPLAIN 语句不是很熟悉——我看到了很多关于如何使用它来优化查询或数据库架构、索引等的信息，但关于如何将它用于我更有限的目的的信息不多- 简单地进行预测，将数据库作为给定（当然，如果预测足够可靠，我最终可能会切换到使用它们也可以在查询可能采用的替代形式之间进行选择，但是，这是为了未来：现在，出于上述目的，我很乐意向用户展示性能猜测）。

任何指针...？

对查询执行 EXPLAIN 后：

由 4 个表的 UNION 组成，我得到这个：

当解释联合的每个组件时，类型是“INDEX”但是联合结果的类型是“ALL”。这种行为的原因是什么？谢谢

在数据库方面，我是一个相对新手。我们正在使用 MySQL，我目前正在尝试加速似乎需要一段时间才能运行的 SQL 语句。我在 SO 上四处寻找类似的问题，但没有找到。

目标是删除表 A 中与表 B 中具有匹配 id 的所有行。

我目前正在执行以下操作：

表 a 中大约有 100K 行，表 b 中大约有 22K 行。'id' 列是两个表的 PK。

这条语句在我的测试机上运行大约需要 3 分钟 - Pentium D, XP SP3, 2GB ram, MySQL 5.0.67。这对我来说似乎很慢。也许不是，但我希望加快速度。有没有更好/更快的方法来实现这一点？

编辑：

一些可能有用的附加信息。表 A 和 B 的结构与我为创建表 B 所做的以下操作相同：

表 a（以及表 b）有一些索引来帮助加快对其进行的查询。同样，我是 DB 工作的相对新手，仍在学习。我不知道这对事物有多大影响，如果有的话。我认为它确实有效果，因为索引也必须清理，对吧？我还想知道是否有任何其他可能影响速度的数据库设置。

另外，我正在使用 INNO DB。

以下是一些可能对您有所帮助的附加信息。

表 A 的结构与此类似（我已经对此进行了一些清理）：

我怀疑部分问题是该表有许多索引。表 B 看起来与表 B 相似，但它只包含列id和h。

此外，分析结果如下：

解决了

感谢所有的回复和评论。他们当然让我思考这个问题。感谢 dotjoe通过提出一个简单的问题“是否有其他表引用 a.id？”让我摆脱了这个问题。

问题是表 A 上有一个 DELETE TRIGGER，它调用存储过程来更新另外两个表 C 和 D。表 C 有一个返回到 a.id 的 FK，并且在存储过程中做了一些与该 id 相关的事情之后，它有声明，

我查看了 EXPLAIN 语句并将其重写为，

所以，我可以看到这是在做什么，它给了我以下信息：

这告诉我这是一个痛苦的操作，因为它会被调用 22500 次（对于被删除的给定数据集），这就是问题所在。一旦我在 other_id 列上创建了一个 INDEX 并重新运行 EXPLAIN，我得到：

好多了，事实上真的很棒。

我补充说 Index_1 和我的删除时间与mattkemp报告的时间一致。这对我来说是一个非常微妙的错误，因为在最后一分钟增加了一些额外的功能。事实证明，正如Daniel所说，大多数建议的替代 DELETE/SELECT 语句最终花费了基本相同的时间，并且正如soulmerge提到的那样，该语句几乎是我能够根据什么构建的最好的语句我需要做。一旦我为另一个表 C 提供了索引，我的 DELETE 很快。

事后分析：
从这个练习中学到了两个教训。首先，很明显，我没有利用 EXPLAIN 语句的强大功能来更好地了解我的 SQL 查询的影响。这是一个菜鸟的错误，所以我不会为此而自责。我会从那个错误中吸取教训。其次，有问题的代码是“快速完成”心态的结果，而设计/测试不足导致这个问题没有尽快出现。如果我生成了几个相当大的测试数据集作为这个新功能的测试输入，我不会浪费我和你的时间。我在数据库方面的测试缺乏我的应用程序方面的深度。现在我有机会改进它。

参考：EXPLAIN 语句

在 Oracle 10g 中有什么好的方法可以客观地衡量查询的性能吗？几天来我一直在调整一个特定的查询。我得到了一个似乎运行得更快的版本（至少基于我的初始测试），但 EXPLAIN 成本大致相同。

1. EXPLAIN 成本遗漏某些东西的可能性有多大？
2. 是否存在 EXPLAIN 成本与查询的实际性能不成比例的特殊情况？
3. 我在这个查询中使用了 first_rows 提示。这有影响吗？