淺析SQL查詢語句未顯式指定排序方式，無法保證同樣的查詢每次排序結果都一致的原因

本文出處：http://www.cnblogs.com/wy123/p/6189100.html 

　　標題有點拗口，
　　先拋出問題：一個查詢沒有明確指定排序方式，那麼，第二次執行這個同樣的查詢的時候，查詢結果會不會與第一次的查詢結果排序方式完全一樣？
　　答案是不確定的，兩個完全一樣的查詢，結果也完全一樣，兩次（多次）查詢結果的排序方式有可能一致，有可能不一致。
　　如果不一致，又是什麼原因導致同樣的查詢預設排序方式不一致？
　　以下簡單分析幾種情況，說明為什麼查詢同樣的查詢會出現預設排序結果不一樣的情況。當然對於該問題，包含但不限於以下幾種情況。

場景1：並行查詢導致預設結果集的排序是隨機的

按照慣例，先造一個表供測試

create table TestDefaultOrder1
(
    id int identity(1,1) primary key,
    col2 varchar(50),
    col3 varchar(50),
    col4 varchar(50),
    col5 varchar(50),
    col6 varchar(50),
    col7 varchar(50),
    col8 varchar(50),
    CreateDate Datetime
)
go

declare @i int =0 
begin tran
    while @i<500000
    begin
        insert into TestDefaultOrder1 values (NEWID(),NEWID(),NEWID(),NEWID(),NEWID(),NEWID(),NEWID(),GETDATE()-RAND()*500)
        set @i=@i+1
    end
commit

測試場景：

　　這裡先不考慮索引之類的性能問題，
　　如圖是一個測試結果的示例，可以看到，兩個查詢的條件是完全一樣的，都沒有顯式指定排序列，預設結果的排序是完全不一樣的

　　甚至可以用同樣的條件做三次查詢（可以更多次），結果依然都是完全不一致的

原因分析：

　　為什麼一樣的查詢，每次查詢結果的排序都不一樣，正如上面所說，這種情況下是並行查詢導致的。
　　查詢引擎採用什麼樣的執行計劃是基於代價考慮的，如果一旦發現一個查詢的執行代價超過一定的閾值，就有可能採用並行的方式來處理，
　　如果採用了並行查詢的方式，就會採用多個線程來分解整個查詢任務，而每一個線程分配的任務量是無法固定的，同時，合併每個線程的結果順序也是不固定的
　　這就導致了最終的查詢結果的順序是不固定的。
　　截圖即為並行查詢的每個線程分配的任務量示例。

　　如圖，當前這個查詢，第一個線程返回的行數是2，但是無法保證第二次查詢的第一個線程返回的行數也是2，
　　即便是第二次返回的行數是2，也無法保證返回的2行與第一次返回的兩行數據一樣的
　　同時，在合併各個線程的結果集的時候，依據線程返回的時間來的，理論上講也是不確定的，多個不確定因素在一起，就造成了最終的結果集排序（可以認為）是隨機的。

場景2：物理存儲導致預設結果的隨機性

　　同樣，先造一個測試數據的case，如下，創建一個堆表，

create table TestDefaultOrder2
(
    id int identity(1,1),
    col2 char(5000)
)
go

declare @i int =0 
begin tran
    while @i<50
    begin
        insert into TestDefaultOrder2 values (NEWID())
        set @i=@i+1
    end
commit

測試場景：

　　這個場景排除了上述並行查詢的影響，因為只有50條數據，根本不會啟用並行查詢
　　如截圖，兩次查詢之間執行了一次表的重建動作，同樣是數據本身沒有發生任何變化，兩次查詢的預設順序完全不一樣

甚至在重建一次，查詢結果仍然與上面兩次還是都不一樣的。

 原因分析：

　　堆表的特點決定了堆內的數據行和數據頁沒有任何固定的順序，整個堆內的數據在物理存儲發生了變化之後，
　　在對查詢（對堆表掃描）的過程中得不到一個與物理存儲變化之前完全一樣的順序。
　　除了上述的重建表會導致查詢的預設順序不一致，其他影響物理空間的操作，都會影響堆表數據頁面的物理存儲位置，

　　比如這裡再執行一次資料庫的收縮，收縮之後的查詢與收縮之前的查詢順序依舊是不一樣的，我可沒有動你表和你表中的任何一條數據，但你不能阻止我正常的資料庫維護操作。
　　總之，一旦影響到物理存儲位置，堆表的預設掃描結果順序都有可能不一樣。

　　以上僅僅通過單表查詢來說明，如果未顯式指定排序方式，即便是同樣的查詢條件，查詢結果的順序是無法保證每次都一致的，
　　如果是多表關聯，或者是考慮到索引，資料庫維護等操作，情況將變得更加複雜，比如這個也比較有意思：http://www.cnblogs.com/wy123/p/5425946.html
　　比較特殊的是：沒有顯式指定排序方式，
　　　　1，某段一個時間段內，查詢結果可能是按照預期結果排序的，某個時間段內就不是了（物理存儲改變的影響）；
　　　　2，某些查詢條件下是按照預期結果排序的，改變一下查詢條件，排序結果就變得面目全非了（執行計劃改變的影響）。
　　總之一句話：沒有顯式執行排序方式，不要期待查詢結果每次都是預期的排序方式，甚至每次都不一樣。

 總結：

　 　本文通過兩個簡單的示例，
　　從執行計劃和物理存儲兩個方面，說明瞭“如果查詢SQL沒有顯式指定排序方式，查詢結果的順序是無法保證總是按照你的預期來的”。
　　當然也不能局限於這兩種情況。
　　然而話不能說死，某些條件下沒有顯式指定排序方式，可能會得到預期的排序結果，但是這種期待往往是不可靠的。
　　

　　“昨天系統查詢結果的排序還是好好的，今天怎麼變了？”
　　“為啥我用A條件查詢是按照時間排序的，按照B條件查詢就不是了？”
　　如果沒有顯式指定排序方式，不要問我資料庫是不是有問題（或者說SQL Server這個資料庫“不行”，或者說DBA說是內部原因是忽悠人的）。

　　所以同學，如果期望查詢結果排序，不管預設是不是你預期的排序方式，都請顯式指定排序方式。