2012-02-02 4 views
7

私は、ストアドプロシージャで"SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED"が異なる順序で行を返すのはなぜですか?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 

を使用するとき、私は異なる順序で行を取得しています。

以下は、ストアドプロシージャで定義されたクエリです。

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; 

SELECT CaseRateDetailId,AmtPerWeek 
FROM CaseRateDetails 
WHERE CaseRateInfoId = @CaseRateInfoId 

それはこのようAmtPerWeekを返します。

10000,15000,5000,20000,25000,.. 

私は

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 

文を使用せずに、同じクエリを実行すると、それは5000,10000,15000,20000,25000,....

すなわち正しい順序で行を返します私は上記の質問でAmtPerWeek句による注文を使用することができますが、私はなぜこのように行動しているのか?なぜそれが行の順序を変更しているのですか?

+8

order by節がない**正しい**注文はありません。 –

+3

いいえ 'ORDER BY' - >定義されていないまたは保証されていないまたは暗黙的な注文 - 注文が必要な場合、' ORDER BY' - **常に必要** ** –

+4

+1それがなぜこのように行動しているのかを知っている」 –

答えて

10

NOLOCKまたはTABLOCKの場合、allocation ordered scanを取得すると、インデックスのリーフレベルではなくファイル順にページを読み取ります。

この方法を使用するかどうかは実行計画には表示されません。 ORDER BYがなければ、注文は保証されません。

+0

それは魅力的です - あなたはそうです、それはショープランには現れません。あなたが間違っていたことが分かったので、私の答えを削除しました。 – Ben

+1

@Ben - プランが「Ordered:False'でインデックススキャンを表示すると、リレーショナルエンジンは行が返される順番を気にしないことを示します。つまり、ストレージエンジンはこれをインデックス>データが変更できない(タブロック)、または分離レベルが、一貫性を保証するスピードを好むような64ページである。割り振り順序付きスキャンは、索引順序付きスキャンよりも並行データ変更の条件の下で、行を見逃す可能性が高く、行を2回読み取る可能性が非常に高くなります。 –

+0

うわー、いいキャッチ! – Alexandre

関連する問題