爲什麼「SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED」以不同的順序返回行？

當我在存儲過程中使用爲什麼「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子句的順序，但我想知道之所以如此行事？爲什麼它會改變行的順序？

來源

2012-02-02 Diya Khan

沒有**正確的**訂單沒有訂單旁邊的條款。 – 2012-02-02 10:35:13

沒有'ORDER BY' - >沒有定義或保證或隱含的順序 - 如果你需要一個命令，你需要有一個'ORDER BY' - **總是** – 2012-02-02 10:39:02

+1「但我想知道它爲什麼這樣做的原因。「 – 2012-02-02 10:59:10

在NOLOCK或TABLOCK下，您可以獲得一個allocation ordered scan，它按文件順序讀取頁面，而不是跟隨索引的葉級別。

它在執行計劃中不顯示它是否使用此方法。沒有ORDER BY沒有訂單保證。

來源

2012-02-02 10:57:06

這很吸引人 - 你是對的，它不會出現在showplan中。刪除我的答案，因爲你已經證明它是錯誤的。 – Ben 2012-02-02 11:52:00

@Ben - 當計劃顯示帶有Ordered：False的索引掃描時，關係引擎表明它並不關心行被返回的順序，這意味着存儲引擎會認爲這是索引> 64頁，並且數據無法更改（tablock）或隔離級別使得它更喜歡速度以保證一致性。與索引有序掃描相比，在併發數據修改的情況下，分配有序掃描更有可能錯過行或讀取兩次行。 – 2012-02-02 12:21:52

哇，很好的接收！ – Alexandre 2012-02-02 18:25:40

爲什麼「SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED」以不同的順序返回行？

回答

相關問題