t sql联合与联接顺序（效率）

我有一个相对简单的问题

我有数据集A和数据集B，它们的结构都相同

最终结果将是数据集a和数据集B的联合，我们称之为数据集C

但在最终版本之前，需要通过连接数据集X来过滤最终数据集

问题是我应该在数据集X上连接数据集A，在数据集X上连接数据集B，然后合并所有A和B，还是应该将所有A和B合并为C，然后在X上连接C

什么更快、内存效率更高等

---

提前谢谢

我的直觉是将两者都加入到x中，然后合并结果。通过这种方式，sql server Optimizer有更好的机会提供最佳查询计划，但在这种情况下，您可能同时编写这两个查询计划，检查执行计划和时间以真正看到差异。

这取决于许多因素，无法从您的问题中得出结论：索引、统计、内部或外部联接、数据类型。你必须知道更多，甚至你真的需要比较执行计划

---

因为我不想重复我自己的话，出于维护的原因，我可能会在工会之外加入，但是如果我不得不打赌，我可能打赌join first的性能会优于它，特别是如果join在行数上大幅减少的话。

我真的希望看到这两种方法的执行计划，并看看什么花费的时间/资源更少

在SQL授权上开始性能调优时。一个从未引起足够关注的话题

---

在优化过程中监控执行计划是一项很好的技术，因为它可以向您展示进一步的索引和其他优化技术是否以及如何在您的执行过程中发挥作用。

您刚刚尝试过它并比较了SSMS中的执行时间和查询计划吗？您认为这里的任何人为什么会处于一种困境更好地告诉您，在硬件上，针对数据的查询，哪一个比您更高效？问题不是在这个特定的查询中，对于这个特定的服务器上的特定数据集，哪一个更高效，我是在问，就sql处理代码的方式而言，对于大型数据集，一个顺序是否更高效。如果没有通用的答案，并且在使用类似大小的数据集时，它比sql server的编码方式有问题要慢或快。如果没有通用的答案，那么sql server的编码方式有问题。我认为您对数据库的理解有问题系统。如果X是一个特殊的事件表，在a&B较大的表中具有良好的索引，并且具有良好的统计信息，那么即使您在派生表中表达了UNION ALL，SQL Server也会首先执行联接。如果您有两个交集良好的小表A和B，以及一个较大的X表，那么联合/排序将发生在联接之前，同样给出了良好的统计信息。除了这些极端，任何事情都会发生。它们都是内部连接。他们不会总是大幅减少排数。我只是运行了几个测试场景，结果如下：对每个数据集执行连接，然后在平均26秒左右完成合并。首先执行union all，然后加入结果，平均结果为21.5秒。这是一个约65k行的结果。对于这么少的行来说，这似乎是一个显著的区别。@jz3我必须了解更多关于数据、代码和执行计划的信息，才能说得更多。