在同一查询中使用UNION和UNION ALL

Question

我遇到了一些性能问题，以下是我的查询：

SELECT * FROM Foo

UNION

SELECT * FROM Boo

UNION

SELECT * FROM Koo

我确定Koo不会返回任何重复项。 我正在考虑在结尾处使用UNION ALL，以便为Koo节省排序和去重选择时间。 查询应如下所示：

SELECT * FROM Foo

UNION

SELECT * FROM Boo

UNION ALL

SELECT * FROM Koo

这会有帮助还是会受到第一个UNION的影响？

- Moslem Ben Dhaou

---

测试两种方法-查看查询计划，看是否有任何区别。 - Oded

@Oded 是的，但前提是你的测试数据和服务器配置是具有代表性的。否则，你可能会基于与你的测试设置相关的（非）优化做出错误的假设。例如，在你的10条记录、单核心、低内存设置上检查查询计划并没有太大用处，如果你打算拥有1000万条记录、32个核心和大量内存的话。 - Jodrell

请注意，Koo 不仅不应该有重复项，而且不应包含在 Foo 或 Boo 中的任何行。 - Lord Peter

Answer 1

如果您确定不会有重复项，请始终使用 UNION ALL。

这里可能有一些不太明确，但仍然值得 - 尽管实际上边缘化了。

如果是直接的 UNION-UNION，SQL Server 可以优化它来汇总所有三个结果集并在两个结果集之间执行单个排序。由于排序大多是 O(n log n)，因此它与 [(A distinct B) add C] 之间几乎没有什么区别。

更新

虽然可以执行单个合并排序，但 SQL Server 似乎并没有这样做（至少不总是） - 因此在这里使用 UNION ALL 的智慧绝对值得。请比较这里的计划：SQLFiddle （点击“查看执行计划”链接）

- RichardTheKiwi

---

如果Koo是一个大表，我会说使用UNION ALL连接Koo有很大的差异...所以我不确定它是否真的是边际的。 - Lukas Eder

如果您对数据有一些有用的了解，告诉查询引擎是有意义的。这可能有助于生成查询计划。 - Jodrell

@Lukas 如果SQL Server将这两个排序优化为单个操作，则变为concat-concat-sort vs concat-sort-concat，其中排序的O（n log n）特性使差异不太明显。由于SQL Server并不总是优化它，因此它肯定比concat-sort-concat-sort快得多。 - RichardTheKiwi