在没有真正的数据仓库数据库之前，现在所有的数据仓库其实都只是一个基于维度模型创建的关系型数据库，但是数据仓库数据库本身有一些区别与比如OLTP数据库的独特特性，比如最显著的就是数据量最大的称为事实的表(一般都有百万甚至上亿的数据量)居于连接的中心，其周围是很多的基数比较小的称为维度的表(可能只有几百行数据)，然后居于中心的大数据量的事实表通过外键连接到十几甚至几十个小数据量的维度表。
针对数据仓库的这种独特的性质，微软在SQL Server 2008之后引入了专门针对数据仓库查询的优化特性：Star Join优化及Few-Outer-Row优化。这两种优化是内置在引擎中的，我们需要做的是遵从一些语句书写方式以从这两种优化中收益。
正如我们在上面所说的，数据仓库的定性设计模式都是中间是大数据量的事实表，周围散布着很多的小数据量的维度表，它们之间使用外键关系彼此联系。而针对数据仓库的查询也共享着基本同样的查询模式：从事实表中选出几个度量值，然后使用外键链接到一个或多个维度表，然后在维度的非主键列上设置过滤条件及做聚合。我们称这种模式为星形模式，
而Star Join优化就是一种特定于数据仓库查询的优化，它通过探索式方法自动识别出一个查询是针对星形模型数据库的查询并识别出事实表，查询优化器然后会为每个参与的维度表构建哈希表，然后基于这些哈希表构建位图过滤器并应用在事实表的扫描中。构建的过滤器会高效地排除应该被接下来的join操作移除的大部分行，因此需要被接下来的操作符处理的数据行会大大减少。
然后问题就是，引擎是如何检测星形模式的呢？它使用如下的探索式方式：
该优化是特定于潜逃循环(nested loop join)，在一些数据仓库查询中，位于嵌套链接外部的维度表一般是一个带过滤的并行扫描。但是如果过滤后只有很少的数据，尤其是如果这些数据还都是处在一个索引页上的时候，SQL Server 2005会在单个线程中选出这些维度数据，这导致所有接下来的工作都在单个线程中完成，这会在一些提供大于1个并行度的环境上造成不平衡的问题。
SQL Server 2008会检测这种嵌套循环连接，并引入了exchange操作符来将少量的外部表的行分发到多个线程中。
原文：http://www.cnblogs.com/wangyubo/p/4445021.html