本文出處：http://www.cnblogs.com/wy123/p/6189100.html 標題有點拗口， 先拋出問題：一個查詢沒有明確指定排序方式，那麼，第二次執行這個同樣的查詢的時候，查詢結果會不會與第一次的查詢結果排序方式完全一樣？ 答案是不確定的，兩個完全一樣的查詢，結果也完全一樣，兩 ...
本文出處：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說是內部原因是忽悠人的）。
所以同學，如果期望查詢結果排序，不管預設是不是你預期的排序方式，都請顯式指定排序方式。
