分区的好处文档列出了以下内容作为分区表的第一个性能优势
当分区列与表连接的列相同时，查询优化器可以更快地处理两个或多个分区表之间的等值连接查询。
同一页面稍后会就此主题进行更详细的说明，但这只是告诉您，连接未以完全相同方式分区的分区表不会获得与连接等效分区表相同的优化。当然，这与前面部分的说法无关；两种分区表方式之间的任何性能比较都与分区与不分区相比的优势无关。
这让我产生了一个疑问：连接等效分区表是否比连接具有相同前导聚集索引键的两个表更快？我很乐意接受实验性的答案或使用相关理论得出结论的答案。
我读过内部原理，也读过很多白皮书和博客，但我认为我没有在任何地方看到过这个问题。我对内部原理的理解让我得出结论，分区方法应该比非分区方法慢。毕竟，分区实际上所做的就是将另一个索引键放在键列表的前面。我自己的实验也发现了同样的结果。
可以，但就像分区一样，这在很大程度上取决于具体情况。在实践中，您可能会看到更好或更差的性能。
无论如何，这更多的是一个查询优化器能力的问题，而不是任何真正根本的问题。正如问题中的最后一个链接所说（强调）：
该链接处的计划形状是：
与常规哈希或合并连接相比，此计划中的交换较少。所示的单个交换使用需求分区，根据需要将新分区 ID 分发给并行线程。
每次对一个分区执行连接，每个分区一个线程。如果要以 DOP 8 处理 64 个分区，则每个线程最终可能会依次处理 8 个分区。运行时可以进行任何其他工作分配，具体取决于每个分区所需的工作量以及线程在其调度程序上获得的时间。
除了由于两个连接输入上没有重新分区交换而释放的内存和线程之外，哈希连接在任何时候最多需要 8 个分区的内存：每个线程都可以重用其用于前一个分区的哈希构建内存。因此，总体内存需求可能比同时在八个线程上处理整个操作要低得多。
当然，基本思想并没有什么神奇之处。假设事先有一组合适的已知范围，可以手动编写一个与未分区表并置的连接；然而，在实现这个想法时，必须小心细节。
其中一个问题是，当数据均匀分布在分区之间并且每个线程在调度程序上获得相同的时间时，它的效果最好。SQL Server 2005 及更早版本中使用的每分区线程模型的缺点是开发索引前缀方法和改进并行线程分布的原因之一，如您的链接中所述。
您可以在我的文章“提高分区表连接性能”中找到性能分析和更多详细信息。
请注意，所有这些主要适用于行模式执行计划。批处理模式计划在线程之间动态分配批处理，并且不使用交换。您仍可能会发现减少最大内存需求会带来一些好处。