在 Informix 中使用 ANSI OUTER JOIN 和 OUTER 时查询计划的差异

发布于 2024-12-17 10:15:00 字数 360 浏览 8 评论 0原文

使用 ANSI 语法的 Informix 查询性能是否有差异:

SELECT .. 
  LEFT OUTER JOIN some_table ON (<condition>) 
  LEFT OUTER JOIN some_other_table (<condition_on_some_table>)

和 Informix 特定的 OUTER 语法:

SELECT ... 
  OUTER (some_table, 
   OUTER(some_other_table)) 
WHERE <join_conditions>

谢谢

is there a difference in the Informix query performance using ANSI syntax:

SELECT .. 
  LEFT OUTER JOIN some_table ON (<condition>) 
  LEFT OUTER JOIN some_other_table (<condition_on_some_table>)

and Informix specific OUTER syntax:

SELECT ... 
  OUTER (some_table, 
   OUTER(some_other_table)) 
WHERE <join_conditions>

thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

灵芸 2024-12-24 10:15:00

是的,标准外连接和 Informix 样式外连接的语义存在差异,这不可避免地意味着查询计划存在差异。

一般来说,对任何新的或修改的代码使用标准表示法 - 为(未更改的)遗留代码保留 Informix 样式的外连接表示法,并且最好甚至更新它以使用新的连接表示法。

有什么区别?公平的问题 - 很难解释,更难想出一个好的(合理的例子)。基本上,Informix 样式表示法会保留“主导”表(非外部表)中的行,即使存在基于外部联接表中的值的条件会拒绝这些行。

这两个查询产生相同的结果:

SELECT i.*, o.*
  FROM DominantTable AS i, OUTER OuterJoinedTable AS o
 WHERE i.pk_column = o.fk_column;

SELECT i.*, o.*
  FROM DominantTable AS i
  LEFT OUTER JOIN OuterJoinedTable AS o
    ON i.pk_column = o.fk_column;

这两个查询不一定产生相同的结果:

SELECT i.*, o.*
  FROM DominantTable AS i, OUTER OuterJoinedTable AS o
 WHERE i.pk_column = o.fk_column
   AND (o.alt_column IS NULL OR o.alt_column = 1);

SELECT i.*, o.*
  FROM DominantTable AS i
  LEFT OUTER JOIN OuterJoinedTable AS o
    ON i.pk_column = o.fk_column
 WHERE (o.alt_column IS NULL OR o.alt_column = 1);

差异发生在这样的情况下:

DominantTable                              OuterJoinedTable
pk_column   other_column                   fk_column   alt_column
1           twenty                         1           3

标准 LEFT OUTER JOIN 表示法将产生空集作为结果。 Informix 样式的联接将产生结果:

pk_column   other_column   fk_column   alt_column
1           twenty         null        null

由于主导表上的过滤条件,来自 DominantTable 的数据未被拒绝,因此它被 Informix 保留。标准连接执行外连接,然后过滤结果。

Yes, there are differences in the semantics of a Standard outer join and an Informix-style outer join which inevitably means that there are differences in the query plan.

In general, use the Standard notation for any new or modified code - leave the Informix-style outer join notation for (unchanged) legacy code, and preferably update even that to use the new join notations.

What is the difference? Fair question - hard to explain, and harder still to come up with a good (plausible example). Basically, the Informix-style notation preserves the rows from the 'dominant' tables (the non-outer tables) even when there are criteria based on the values in the outer-joined table that would reject those rows.

These two queries produce the same result:

SELECT i.*, o.*
  FROM DominantTable AS i, OUTER OuterJoinedTable AS o
 WHERE i.pk_column = o.fk_column;

SELECT i.*, o.*
  FROM DominantTable AS i
  LEFT OUTER JOIN OuterJoinedTable AS o
    ON i.pk_column = o.fk_column;

These two queries do not necessarily produce the same result:

SELECT i.*, o.*
  FROM DominantTable AS i, OUTER OuterJoinedTable AS o
 WHERE i.pk_column = o.fk_column
   AND (o.alt_column IS NULL OR o.alt_column = 1);

SELECT i.*, o.*
  FROM DominantTable AS i
  LEFT OUTER JOIN OuterJoinedTable AS o
    ON i.pk_column = o.fk_column
 WHERE (o.alt_column IS NULL OR o.alt_column = 1);

The difference occurs in a situation like this:

DominantTable                              OuterJoinedTable
pk_column   other_column                   fk_column   alt_column
1           twenty                         1           3

The standard LEFT OUTER JOIN notation will produce the empty set as the result. The Informix-style join will produce the result:

pk_column   other_column   fk_column   alt_column
1           twenty         null        null

The data from DominantTable was not rejected because of a filter condition on the dominant table, so it is preserved by Informix. The standard join does the outer join and then filters the result.

窗影残 2024-12-24 10:15:00

测试并找出答案,或者发布两者的执行计划,我们将帮助消化它们。

在其他当前的数据库引擎中,它们将导致相同的执行计划进行适当的优化。

Test and find out, or post the execution plans for both and we'll help digest them.

In other current database engines they will result in the same execution plan to due optimization.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文