如果子查询返回太多数据，我应该担心吗？

Question

以下是示例：

 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（没有过滤条件）组合来自多个表的数据然后，子查询返回的foreach行，join获取我需要在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....

Answer 1

1. 是的。
2. 不，查询优化器将整个查询视为一个块。它不运行派生表，然后对结果运行外部语句。它通过'派生表来优化。
3. 再一次，没有。拥有派生表并不意味着性能不佳。您总是需要查看整个查询。
4. 这不是问题。
5. 然后那就好了。信任查询优化器。你见过写过它的人吗？他们吓人智能。

在每个案例中，值得查看您的查询执行计划并找到痛点。当他们可以进行搜索时，查找正在进行扫描的事物，这通常会给你带来显着的提升。事情是扫描而不是寻求：

• 没有索引要求
• 您正在寻找的是功能的结果（例如WHERE function(field) = value）
• 优化程序决定扫描实际上更快。

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