2

次のようなかなり複雑なクエリがあります。

create table Items(SomeOtherTableID int,SomeField int)
create table SomeOtherTable(Id int,GroupID int)
with cte1 as
(
    select 
        SomeOtherTableID,COUNT(*) SubItemCount 
    from 
        Items t 
    where 
        t.SomeField is not null 
    group by 
        SomeOtherTableID

),cte2 as
(
    select
        tc.SomeOtherTableID,ROW_NUMBER() over (partition by a.GroupID order by tc.SubItemCount desc) SubItemRank
    from 
        Items t
        inner join SomeOtherTable a on a.Id=t.SomeOtherTableID 
        inner join cte1 tc on tc.SomeOtherTableID=t.SomeOtherTableID
    where 
        t.SomeField is not null 

),cte3 as
(
    select 
        SomeOtherTableID 
    from 
        cte2 
    where 
        SubItemRank=1
)
select 
    * 
from 
    cte3 t1 
    inner join cte3 t2 on t1.SomeOtherTableID<t2.SomeOtherTableID 
option (maxdop 1)

クエリは、cte3が6222 の異なる結果で満たされるようなものです。最終選択では、 cte3でそれ自体とのクロス結合を実行しています（後で、テーブル内のすべての値をテーブル内の他のすべての値と比較できるようにするため）。最後の行に注意してください：

option (maxdop 1)

どうやら、これは並列処理をオフにします。

したがって、cte3に6222の結果行がある場合、（6222 * 6221）/ 2、または19353531の結果が後続の交差結合選択になり、最後のmaxdop行が配置されると予想されます。

ただし、maxdop行を削除すると、結果の数は19380454にジャンプします。開発ボックスに4つのコアがあります。

WTF？誰かがこれがなぜであるか説明できますか？このように相互結合する以前のクエリを再検討する必要がありますか？

4

2 に答える 2

0

SCOPE_IDENTITYにも同様のパラリズムバグがあるようです

それとも、別のバグであるスナップショット分離を使用していますか? 特定の条件下でスナップショット分離が一時的にオフになっていることを示すブログもいくつかあります。

編集：

スナップショット分離の 3 番目に戻る:並列処理について神経質になるべき 6 つの理由

于 2009-05-10T09:25:22.287 に答える
0

バグは別として、並列処理は結果に影響を与えるべきではありません。

于 2009-05-10T02:59:33.590 に答える