淺析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說是內部緣由是忽悠人的）。

　　因此同窗，若是指望查詢結果排序，無論默認是否是你預期的排序方式，都請顯式指定排序方式。