淺析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行與第一次返回的兩行數據一樣的
　　同時，在合並各個線程的結果集的時候，依據線程返回的時間來的，理論上講也是不確定的，多個不確定因素在一起，就造成了最終的結果集排序（可以認為）是隨機的。

　　

　　

　　有人說，只要執行計划一樣，查詢默認排序就一樣，其實也是不對的，因為即便是執行計划一樣，只要SQLServer開啟了並行查詢，默認排序都是無法保證一直的 　　

 

 

場景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說是內部原因是忽悠人的）。

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