2

这是示例：

 SELECT <columns>   
 FROM (..........<subquery>..........) AS xxx  
 INNER JOIN(s) with xxx.............  
 LEFT OUTER JOIN(s) with xxx........  
 WHERE <filter conditions>

如果我错了，请纠正我：

  1. 那<subquery>是派生表吗？
  2. 如果它返回关于服务器内存的太多数据（比如数百万行）是否有问题，因为我知道 WHERE 子句应用于最终结果集并且即使最终结果有 10 个子查询也让服务器处理太多子查询行？
  3. 如果没有内连接（以减少数据）并且只有左外连接怎么办，这是否会使事情变得更糟/更慢，因为它必须与子查询中的所有行进行连接？
  4. 如果（2）是一个问题，那么我想到的一种解决方案是通过在其中添加其他联接来限制子查询返回的数据，这会使事情变慢（我已经尝试过了）。对此还有其他想法吗？
  5. 如果由于 where 子句依赖于子查询之后的连接，我无法限制子查询的结果怎么办？
  6. 为了澄清事情，子查询返回太多数据的原因是因为我正在尝试使用 UNION ALL 组合来自多个表的数据（没有过滤条件），然后，对于子查询返回的每一行，加入以获取我的信息需要在 WHERE 子句中使用它。另一种方法是对子查询内部的每个 UNION ALL 执行您在子查询外部看到的所有连接，是的，这确实限制了结果集，但会产生更多连接，正如我所说，这会减慢速度。换句话说，我必须在执行此操作的子查询之间进行选择：
 (
 SELECT * FROM A UNION ALL
 SELECT * FROM B UNION ALL
 SELECT * FROM C...
 ) AS xxx
 left outer join T with xxx

和

 SELECT * FROM A
 LEFT OUTER JOIN T ...
 WHERE....
 UNION ALL
 SELECT * FROM B
 LEFT OUTER JOIN T ...
 WHERE....
 UNION ALL
 SELECT * FROM C
 LEFT OUTER JOIN T ...
 WHERE....
4

1 回答 1

2
  1. 是的。
  2. 不，查询优化器将整个查询视为一个块。它不运行派生表，然后对结果运行外部语句。它通过派生表“优化”。
  3. 再次，不。拥有派生表并不意味着性能不佳。您始终必须将查询视为一个整体。
  4. 这算不上问题。
  5. 然后就好了。信任查询优化器。你见过写它的人吗？他们是可怕的聪明人。

在每种情况下，都值得查看您的查询执行计划并找出痛点。在可以进行搜索时寻找正在扫描的事物，这通常会给您带来显着的提升。在以下情况下，事物会扫描而不是寻找：

  • 没有可搜索的索引
  • 您正在寻找的东西是函数的结果（例如WHERE function(field) = value）
  • 优化器决定扫描实际上更快。

但问题的底线答案是 - 不，如果您单独选择派生表，您不应该担心派生表会包含大量数据。

于 2012-12-10T14:02:24.413 回答