【问题标题】:How inefficient are virtual table JOINs?虚拟表 JOIN 的效率有多低?
【发布时间】:2011-07-30 01:09:39
【问题描述】:

假设我有一个这样的查询,我在其中加入了许多虚拟表:

SELECT table1.a, tbl2.a, tbl3.b, tbl4.c, tbl5.a, tbl6.a
FROM table1
JOIN (SELECT x, a, b, c FROM table2 WHERE foo='bar') tbl2 ON table1.x = tbl2.x
JOIN (SELECT x, a, b, c FROM table3 WHERE foo='bar') tbl3 ON table1.x = tbl3.x
JOIN (SELECT x, a, b, c FROM table4 WHERE foo='bar') tbl4 ON table1.x = tbl2.x
JOIN (SELECT x, a, b, c FROM table5 WHERE foo='bar') tbl5 ON table1.x = tbl5.x
JOIN (SELECT x, a, b, c FROM table6 WHERE foo='bar') tbl6 ON table1.x = tbl6.x
WHERE anotherconstraint='value'

在我的真实查询中,每个 JOIN 都有自己的 JOIN、聚合函数和 WHERE 约束。

这样的查询运行得有多好/差?另外,这与将所有单独的虚拟表作为自己的查询运行并将结果在 SQL 之外链接在一起之间有什么影响差异?

【问题讨论】:

  • 你的意思是,反对真正的表连接?简介吧!这将取决于许多因素,其中很多将取决于您的数据/模式。此外,在 SQL 之外链接结果很可能会慢很多。如果您发现巨大的性能问题,您可能需要在所有表中的 x 或 foo 上建立索引
  • 在我的实际查询中,每个 JOIN 都有许多其他 WHERE 子句约束、附加连接和聚合函数,这就是我将它们拆分为虚拟表的原因。也许有更好的方法来解决它?
  • 如果每个子查询都很复杂,那么您真的应该对其进行分析。查看执行计划并了解如何阅读它们。

标签: sql oracle


【解决方案1】:

使用内联视图本身并没有什么坏处(AFAIK 是您所谓的“虚拟表”的正确术语)。我确实建议您学习查看和理解执行计划,以便调查具体的性能问题。

一般来说,我认为执行多个单表查询然后在前端代码中将结果连接在一起是一个非常糟糕的主意。做连接是 RDBMS 的设计目的,为什么要重写它?

【讨论】:

    【解决方案2】:

    为什么不只是:

    SELECT table1.a, tbl2.a, tbl3.b, tbl4.c, tbl5.a, tbl6.a
    FROM table1 JOIN table2 on table1.x = table2.x AND table2.foo = 'bar'
                JOIN table3 on table1.x = table3.x AND table3.foo = 'bar'
                JOIN table4 on table1.x = table4.x AND table4.foo = 'bar'
                JOIN table5 on table1.x = table5.x AND table5.foo = 'bar'
                JOIN table6 on table1.x = table6.x AND table6.foo = 'bar'
    WHERE anotherconstraint='value';
    

    编辑:

    它的运行情况如何?谁知道?正如@Vinko 所说,答案在于查看执行计划,也许在适当的地方提供提示。看一个人为的例子是无法回答这种复杂问题的。

    【讨论】:

    • 查看我上面的编辑——每个虚拟表 JOIN 都有自己的 JOIN、聚合函数和 WHERE 约束。
    猜你喜欢
    • 1970-01-01
    • 2017-05-27
    • 2016-12-04
    • 2016-11-10
    • 2012-10-06
    • 2022-01-20
    • 2015-09-29
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多