问题标签 [sql-execution-plan]

关于 SQL 中语句的执行顺序，以下性能方面有什么区别？

和：

如果有任何区别，是否可能有链接等，您可以在其中了解更多信息？

万分感谢，

凯尔

我看不出执行计划有什么问题。此外，据我了解，SQL Server 2000 通过识别针对现有执行计划的 T-SQL 语句的新 T-SQL 语句（通过保留所有 SQL 语句的执行计划），将存储过程的许多性能优势扩展到所有 SQL 语句。过程缓存，而不仅仅是存储过程执行计划）

这是一个相当直接的 SELECT 语句，具有合理的表连接，查询中不包含任何事务或链接的服务器被引用，并且应用了 WITH (NOLOCK) 表提示。存储过程由 dbo 创建，用户拥有所有必要的权限。

所以我的问题是：

当通过存储过程运行相同的 T-SQL 时，查询只需要几秒钟即可运行但随后需要几分钟的可能原因是什么？

我们有一个有趣的问题，我希望有人能帮助解释一下。在高层次上，问题如下：

以下查询快速执行（1 秒）：

但是如果我们在查询中添加过滤器，则大约需要 2 分钟才能返回：

查看两个查询的执行计划，我可以看到在第二种情况下，实际行数和估计行数之间存在巨大差异的两个地方是：

1) 对于 FulltextMatch 表值函数，其中估计约为 22,000 行，实际为 2900 万行（然后在连接前过滤到 1670 行）和 2) 对于全文索引上的索引查找，其中估计为 1 行，实际为 13,000 行

作为估计的结果，优化器选择使用嵌套循环连接（因为它假设行数很少），因此该计划效率低下。

我们可以通过 (a) 参数化查询并向查询添加 OPTION (OPTIMIZE FOR UNKNOWN) 或 (b) 通过强制使用 HASH JOIN 来解决该问题。在这两种情况下，查询都会在不到 1 秒的时间内返回，并且估计值看起来很合理。

我的问题真的是'为什么在表现不佳的情况下使用的估计如此不准确，可以做些什么来改进它们'？

此处使用的索引视图上的索引的统计信息是最新的。

非常感谢任何帮助。

我正在比较查询我的开发和生产数据库。

它们都是 Oracle 9i，但几乎每个查询都有完全不同的执行计划，具体取决于数据库。

所有表/索引都是相同的，但 dev 数据库中每个表的行数大约为 1/10。

在生产环境中，它为大多数查询选择的查询执行计划与开发环境不同，而且成本有时会高出 1000 倍。在某些情况下，生产中的查询似乎也没有使用正确的索引进行查询（全表访问）。

我最近也在这两个数据库上运行了 dbms_utility.analyze 模式，希望 CBO 能解决一些问题。

是否有其他一些潜在的 oracle 配置可能导致这种情况？

我主要是一名开发人员，所以这种 DBA 分析起初相当混乱。

我从一篇“执行计划”文章中看到了一些东西：

（链接：http ://explainextended.com/2009/09/18/not-in-vs-not-exists-vs-left-join-is-null-mysql/ ）

为什么显示 2 个持续时间？如果我还没有大数据集怎么办。例如，如果我只有 20 条、50 条，甚至只有 100 条记录，我无法真正衡量 2 条不同的 SQL 语句在现实生活中的速度相比有多快？换句话说，至少需要几十万条记录，甚至上百万条记录，才能准确比较这两条不同 SQL 语句的性能？

我们正在运行 MS SQL 2005，过去几天我们遇到了一个非常特殊的问题。

我有两个过程，一个创建每小时的数据报告。另一个调用它，将它的结果放在一个临时表中，并进行一些聚合，然后返回一个摘要。

他们工作得很好……直到第二天早上。

第二天早上，突然来电报告，抱怨列名无效。

修复，只是调用过程的重新编译，一切正常。

这怎么可能发生？自从将这些 proc 投入生产以来，这已经连续三个晚上发生了。

编辑：看来，调用者（摘要）过程不需要重新编译。我只是能够通过执行被调用者（每小时）过程来解决问题。然后执行摘要过程。这比以前更没有意义。

EDIT2：每小时的过程相当大，我没有将其全部发布在这里。但是，最后，它会执行 SELECT INTO，然后有条件地从创建的临时表中返回适当的结果。

然后它会删除所有临时表并结束。

来电者（摘要）

首先创建一个临时表#tmpTodaySales 来存储结果，列列表与另一个过程中#tmpResults 的定义匹配。然后它最终调用了几次每小时的过程

我相信正是这些电话失败了。但是重新编译过程，或在此之外执行每小时过程，然后调用摘要过程可以解决问题。

问题：

DateTime.Now作为参数传递给 proc 是否会阻止 SQL Server 缓存查询计划？如果是这样，那么 Web 应用程序是否错过了巨大的性能提升？

可能的解决方案：

我认为DateTime.Today.AddDays(1)这将是一个可能的解决方案。它会将相同的结束日期传递给 sql proc（每天）。并且用户仍然会得到最新的数据。请也谈谈这个。

给定示例：

假设我们有一个存储过程。它将数据报告给网页上的用户。用户可以设置日期范围。如果用户将今天的日期设置为“结束日期”，其中包括今天的数据，则 Web 应用程序将传递DateTime.Now给 sql proc。

假设一个用户多次运行报告5/1/2010--to-- now。在网页上，用户5/1/2010看到5/4/2010. 但是 Web 应用程序DateTime.Now作为结束日期传递给 sql proc。因此，过程中的结束日期总是不同的，尽管用户正在查询类似的日期范围。

假设表中的记录数和用户数很大。因此，任何性能提升都很重要。因此问题的重要性。

过程和执行示例（如果这有助于理解）：

这是使用 DateTime.Now 的示例执行：

这是使用 DateTime.Today.AddDays(1) 的示例执行

两个过程返回相同的数据，因为当前时间是：2010-05-04 15:41:27。

我有一个使用 EXECUTE IMMEDIATE 调用的存储过程。我面临的问题是，当我直接调用该过程与使用 EXECUTE IMMEDIATE 调用该过程时，解释计划是不同的。这导致执行时间增加了 5 倍。计划之间的主要区别在于，当我使用立即执行时，优化器不会取消嵌套子查询（我使用的是 NOT EXISTS 条件）。对于大多数查询，我们在这里使用基于规则的优化器，但是这个提示使用索引，因此正在使用 CBO（但是，我们不收集表上的统计信息）。我们正在运行 Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production。

示例：快速：

慢的：

询问：

好的解释计划：

糟糕的解释计划：

在糟糕的解释计划中，子查询没有被取消嵌套。通过向子查询添加 no_unnest 提示，我能够重现错误的计划；但是，我无法使用 unnest 提示重现好计划（当使用执行立即运行该过程时）。当使用立即执行而不是未嵌套提示时，优化器正在考虑其他提示。

仅当我使用 execute immediate 调用该过程时才会出现此问题。如果我在查询本身上使用立即执行，它会使用好的计划。

我有这样的查询（由 LINQ 创建）：

DataFTS 是一个全文搜索表值函数。查询执行计划如下所示：

这是否意味着 WHERE 子句 ([CreatorId] = 1)在 TVF（全文搜索）之前或全文搜索之后执行？TVF 是查看缩小的数据集（由 WHERE 子句缩小）还是查看整个表？

TVF 如下所示：

谢谢你。

我正在努力为让我发疯的问题找到解决方案......

我有一个查询在 QA 服务器中运行得非常快，但在生产中却很慢。我意识到他们有不同的执行计划......所以我尝试重新编译，清理执行计划的缓存，更新统计信息，检查排序规则的类型......但我仍然找不到发生了什么......

运行查询的数据库完全相同，SQL Server 也具有相同的配置。

任何新的想法将不胜感激。

谢谢。

我刚刚意识到 QA 服务器正在运行 SP3，而生产中是 SP2。这对这个问题有什么影响吗？