问题标签 [sql-execution-plan]

我正在尝试优化查询，但不太了解从Explain Plan返回的一些信息。谁能告诉我 OPTIONS 和 COST 列的意义？在 OPTIONS 列中，我只看到 FULL 一词。在 COST 列中，我可以推断出较低的成本意味着更快的查询。但是成本值究竟代表什么，什么是可接受的阈值？

在 SQL Server 2005 上，我有一个复杂的多级分配过程，如下所示（伪 SQL）：

WhereALLOCS以直接分配为种子，然后BALANCES(@LVL_NUM)基于ALLOCSat @LVL_NUM（可能是一些直接分配加上前一级别的一些 IN 分配），并且ALOCNS(@LVL_NUM)基于BALANCES(@LVL_NUM)并且ALOCN_SUMRY(@LVL_NUM)仅基于ALOCNS(@LVL_NUM)- 有很多配置表，这些配置表指示驱动程序将分配赶出去。

这被简化了，但实际上循环中有四五对这样的对，因为有多种逻辑无法一起处理（有些情况可以一起处理）。

其基本逻辑是在特定成本中心/产品线/等（即）中获取总金额，然后根据其在特定成本中心/产品线/等中的份额（即百分比份额）将BALANCES其分配给另一个成本中心/产品线/等。ALLOCNS / ALLOCN_SUMRY公制。

在记录OUT保存IN和SUMRY.ALLOCN是一个加号！）。（现有的系统是一个怪物 C/C++/MFC/ODBC 程序，它将所有数据读入海量数组和其他数据结构中，编写得非常糟糕。）

问题似乎是，当在循环中运行时，我似乎遇到了执行计划问题，因为随着ALLOCS表格开始发生变化（并且一切都在变化，因为级别有不同的成本中心，所以配置被用来驱动ALLOCNS正在改变）。我认为我最多有 99 个级别，但最低级别从 2、4、6 开始。似乎@LVL_NUM = 6在 UDF 之外单独运行表现良好，但 UDF 表现不佳 - 可能是因为 UDF 有缓存计划或整体计划已经很糟糕了，因为在ALLOCS前面的步骤中添加了@LVL_NUM IN (2, 4)。

在开发早期，我设法在 30 分钟内完成了 30 个关卡，但现在我无法在 2 小时内完成前 3 个关卡。

我正在考虑在另一个 SP 中运行这两个插入并将其称为 WITH RECOMPILE，但很好奇这个 RECOMPILE 是否正确级联到 TVF UDF？任何其他建议也将不胜感激。

真实代码：

这是我的测试批次，最终将在单个 SP 中运行整个过程。您可以从注释掉的部分看到我也一直在使用临时表和表变量：

我有一个有两个索引的表；一个是多列聚集索引，在 3 列上：

第二个是非聚集在

我试图运行的选择语句是：

我使用 sql management studio 编辑器在 sql2008 上运行此查询并启用实际执行计划，我发现 sql 使用第二个索引和 propse 为三列（symbolid、bartime、typeid）创建一个新索引但非聚集！！！（我认为它说的是非聚集索引，因为已经有一个聚集索引）

这个选择是错误的，我再次重新运行相同的查询并强制 SQL 使用聚集索引（使用“with index”）并且性能应该更好。

我在这里有两个问题，一个与此行为有关，第二个与查询本身有关

1. 为什么 SQL 选择错误的索引并支持相同的索引
2. 在这种情况下我应该使用哪一个以"where"获得更好的性能

符号在 (1010,1020,1030,1040,1050,1060)

（符号 = 1010 或符号 = 1020 ..等）

（符号介于 (1010 和 1060) 之间）

测试后

我发现当我将 where 条件从使用 IN 更改为使用 >= 和 <= bartime 列上的非聚集索引比 3 列上的聚集索引提供更好的性能。

所以我有两种情况，如果 WHERE 使用 IN 最好使用聚集索引，如果它包含 >= 和 <= 它使用第二个。

如果我运行以下 SQL 查询

该WHERE语句是在 ? 之前还是之后进行评估的JOIN？

如果之后，编写此语句的更好方法是什么，以便仅返回Afrom"Yesterday"中的行 join to B？

我正在玩 SQL 查询，我想到了这个 - select x,y from table T.

这里 x 和 y 可以是算术表达式，例如 2.0/5.0 OR 1+2，结果是表 T 的行数，第一列的值为 2.0/5.0，即 0.444444，第二列的值为 3。

我很想知道这个查询是如何执行的。我了解到，在 SQL 查询引擎中，存在从查询的 SQL 表示到内部表示（如关系代数）的映射，然后对其进行优化以产生最佳的查询执行计划。

如果它是错误的，请纠正我的理解 - 对于我所说的查询，从我的查询 Q 到内部表示之间会有一个内部映射，它相当于select * from table T. 然后对于所有返回的行，n 个列被投影出来，其中 n 是 Q 中所述的算术表达式的数量。n 列的所有行都将具有它们各自对算术表达式的评估。

干杯

我们的网站受到了相当大的冲击，因此我们正在研究优化我们现有的一些查询。

在研究这个问题时，我们遇到了几个查询，当查询中包含聚集索引的简单引用时，它们的执行计划快了大约 4-5 倍……例如

如果这是旧查询：

根据 SSMS 中的执行计划，以下查询将快 4 倍：

我们似乎无法理解这将如何使查询更快。聚集索引位于 lotID 上，但由于它与自身进行比较，这有什么帮助？

我有一个相当复杂的连接的执行计划，它显示在“实际行数”读取〜70,000的表上执行索引搜索，而实际上表中总共只有〜600行（估计数行数仅为 127）。

请注意，所有统计信息都是最新的，查询的输入参数与编译 proc 时输入的参数完全相同。

为什么实际行数这么高，“实际行数”这个数字到底是什么意思？

我唯一的理论是大量的行与嵌套循环有关，并且这个索引搜索被执行了多次——“实际行数”实际上代表了所有执行的总行数。如果是这种情况，估计的行数是否也意味着所有执行的总行数？

我有一个存储过程，它接受一个日期输入，如果没有传入任何值，则稍后将其设置为当前日期：

我遇到了问题，如果在首次编译存储过程时@MyDate传入，NULL则所有输入值（或其他）的性能总是很糟糕NULL，如果在编译存储过程时传入日期/当前日期所有输入值（NULL或其他）的性能都很好。

同样令人困惑的是，即使 @MyDate 使用的值实际上是 NULL（而不是CURRENT_TIMESTAMP由 IF 语句设置），生成的糟糕的执行计划也很糟糕

我发现禁用参数嗅探（通过欺骗参数）可以解决我的问题：

我知道这与参数嗅探有关，但是我看到的所有“参数嗅探变坏”的示例都涉及使用传入的非代表性参数编译存储过程，但是在这里我看到了执行计划对于 SQL 服务器可能认为参数可能在执行语句的点可能采用的所有可能的值是可怕的 -NULL或CURRENT_TIMESTAMP其他。

有没有人知道为什么会这样？

Oracle 10g 中的（空间）查询仅根据参数值获得不同的执行计划。遗憾的是，甲骨文根本无法执行其中一个计划，从而出现错误。更改值（低于 282 到 284）或运算符（= 到 <）给出结果。为什么计划不同？为什么 oracle 选择一个不可执行的计划？怎么做才能强制Oracle选择一个可执行的执行计划？

查询：

给出错误：

不执行的计划：

执行并给出结果的计划

我继承了一个有点混乱的查询，我正在努力重构以提高性能。

在此过程中，由于个人喜好，我所做的一件事是将所有 ANSI-99 连接语法从“内连接”和“左外连接”语句更改为查询中的谓词。我注意到两件非常奇怪的事情，我希望能得到解释。

1. 从“INNER JOIN...”语法更改联接已更改解释计划。使用 ANSI 99 语法，oracle 对正在连接的列进行全表扫描。更改连接语法后，它现在执行谓词推送。为什么连接语法会改变解释计划？
2. 推入内联视图的谓词实际上大大减慢了查询速度。正在运行的查询（在更改连接之前）大约 3 秒。现在需要 9 秒。老实说，我对阅读解释计划相当陌生，因此查询的重组完全有可能由于不同的原因而减慢了速度。但最终我的问题是：“推索引列的谓词是否有可能大幅减慢查询速度？如果是，为什么？”

感谢您的回复，如果这不是很清楚，我很抱歉...