在今天的文章里，我想談下SQL Server里非常有爭議和復雜的話題：ORDER BY子句的歧義性。

我們用一個非常簡單的SELECT語句開始。

1 -- A very simple SELECT statement2 SELECT * FROM Person.Person3 ORDER BY LastName4 GO

從剛才列出的代碼你可以看到，我們只想從Person.Person表以LastName列排序返回記錄。因為我們想能盡可能簡單的重用那個SQL語句，最后我們把它放到視圖里，如下：

1 -- This doesn't work2 CREATE VIEW v_Persons3 AS4     SELECT * FROM Person.Person5     ORDER BY LastName6 GO

但是你會看到，SQL Server不能創建那個視圖，只返回一個錯誤信息：

這個錯誤信息告訴你，的那個你不使用TOP，OFFSET或FOR xml表達式時，在視圖里你不允許使用ORDER BY子句。基于那個錯誤信息，我們可以通過增加TOP 100 PERCENT子句到視圖里在輕松修正問題。

1 -- Let's make it work!2 CREATE VIEW v_Persons3 AS4     SELECT TOP 100 PERCENT * FROM Person.Person5     ORDER BY LastName6 GO

現在視圖創建沒有任何問題！我們對視圖執行一個SELECT語句。

1 SELECT * FROM v_Persons2 GO

SELECT語句本身可以執行，但當你看返回的數據時，瘋狂的事情發生了：返回的數據沒有按LastName列排序——SQL Server按BusinessEntityID——表上的聚集鍵列排序！

這是SQL Server里的BUG么？不，并不是——它是“故意的”！我們來解釋下為什么。首先你要知道ORDER BY子句在SQL（編程語言本身）里用2個不同的上下文：

1. 使用ORDER BY子句你可以定義返回給你客戶端程序的排序
2. 另外ORDER BY子句用來定義從TOP表達式哪些行返回

你必須知道的最重要的事情是，你用視圖定義了所謂的集合（Set），行內函數，派生表，子查詢和通用表表達式（common table exPRessions（CTE））。集合是數學上的概念，關系數據庫（例如SQL Server）上集合論（Set Theory）的組成。集合本身是沒有排序的。因此用視圖定義與ORDER BY組合是不允許的——如你剛才所見。如果你嘗試這樣做，SQL Server不允許你這樣做并給你一個錯誤信息。

當然你可以在與TOP表達式里組合使用ORDER BY。但基本上你在愚弄SQL Server和你自己，因為ORDER BY沒有告訴SQL Server要以怎樣的排序返回數據給客戶端程序。假設你使用TOP 10 PERCENT。表的前10%是什么？你需要確定性的方式里定義排序。

而且因為我們必須使用TOP 100 PERCENT與ORDER BY組合，查詢優化器實際上在執行計劃里不會引入排序運算符。TOP 100 PERCENT意味著一切，因此如你在下圖所看到的，在執行計劃里TOP運算符不需要排序輸入。

在這個例子里，我們的返回行以從內在數據結構讀取的排序。這由SQL Server的存儲引擎來決定返回行的排序。這里我們從聚集索引里讀取行。因此我們拿到的數據按BusinessEntityID排序，這是索引列里聚集鍵值。

現在我們修改下視圖定義，從Person.Person表值返回10%的行。我們還是指定了ORDER BY子句。

1 -- Alter the view2 ALTER VIEW v_Persons3 AS4     SELECT TOP 10 PERCENT * FROM Person.Person5     ORDER BY LastName6 GO

當你現在看結果集時，你會看到返回的行按LastName列排序的?，F在才對了，因為你在執行計劃里看到了排序運算符（SQL Server 2014里沒有出現），因為TOP運算符最后能返回提供輸入行的前10%的數據。

當然你可以通過ORDER BY子句在你引用的視圖里按不同的排序返回10%的行給你的客戶端程序。

1 SELECT * FROM v_Persons2 ORDER BY FirstName3 GO

現在當你看執行計劃時，你會在計劃里看到2個（SQL Server 2014里只有1個）。

第1個（右邊）排序運算符為TOP運算符預排序（返回前10%）。第2個（左邊）排序運算符用來最后定義的排序，返回給客戶端程序。當你通過添加TOP 100 PERCENT來定義的視圖里強制ORDER BY——你基本上就在愚弄SQL Server……

另一個問題是沒有ORDER BY子句的TOP表達式不會提供你確定性的結果。我們可以用具體的例子演示下這個問題。假設有下列SELECT語句：

1 SELECT TOP 1 LastName FROM Person.Person2 GO

這個SQL語句用TOP 1表達式返回Person.Person表的第一行——沒有用ORDER BY子句定義排序。這個排序是基于執行計劃里選擇的索引。在這個例子里SQL Server返回你“Abbas”給你作為結果，因為這是執行計劃里查詢優化器選擇非聚集索引里第1條可用記錄。

因此從這個查詢返回的第1條記錄取決于執行計劃里選擇的索引。如果現在我們把非聚集索引停用呢。

1 -- Let's deactivate this index2 ALTER INDEX [IX_Person_LastName_FirstName_MiddleName] ON Person.Person3 DISABLE4 GO

然后當你再次執行剛才的SELECT語句，SQL Server返回你Sánchez值，意味只是在執行計劃里現在選擇的聚集索引的第1條記錄。SQL Server從聚集索引里返回了用BusinessEntityID值為1的第1行。

因此你與非確定性記錄打交道時：你的結果取決與執行計劃里選擇的索引！你可以通過增加ORDER BY子句來輕松實現查詢結果排序的明確性。在這個情況下ORDER BY子句為TOP表達式使記錄確定——這樣話在執行計劃里你會有Sort（Top N Sort）的運算符。

1 SELECT TOP 1 LastName FROM Person.Person2 ORDER BY LastName3 GO

在執行計劃里，SQL Server從哪個索引讀取行并不重要——Sort（Top N Sort）的運算符在執行計劃里會物理預排序行，并從它返回第N行——很簡單，是不是？

在SQL（編程語言本身）里ORDER BY子句并不是一個最簡單的概念。如你在這篇文章里所學的，ORDER BY使用2個不同的上下文，因此你總要考慮下你要使用哪個上下文。永遠不要在視圖定義里增加TOP 100 PERCENT來愚弄SQL Server和你自己——它不會在最終的記錄集里體現排序。

感謝關注！