SQL Server 無 ORDER BY 時的排序行為：不保證依主鍵，實際取決於執行計劃

核心結論

SQL Server 不保證無 ORDER BY 查詢的輸出順序。 實際順序取決於查詢最佳化器選擇的執行計劃（使用哪個索引、掃描方式、平行處理等），任何不加 ORDER BY 的查詢都可能在統計資料更新、索引重建、平行度變更、參數嗅探等情況下產生不同順序。

實測案例說明

測試環境

• 資料表 AttendanceEmpRank
• 主鍵 AttendanceEmployeeRankId（叢集索引）
• 另有一非叢集索引 Date

查詢 1：未指定 ORDER BY

SELECT * FROM AttendanceEmpRank;

執行計劃：使用 Date 非叢集索引掃描 → 輸出順序依 Date 排序。

查詢 2：指定 ORDER BY 主鍵

SELECT * FROM AttendanceEmpRank ORDER BY AttendanceEmployeeRankId;

執行計劃：使用叢集索引掃描 → 輸出順序依主鍵排序。

結果差異

兩次查詢輸出順序明顯不同，證明無 ORDER BY 時不走主鍵順序。

為什麼會這樣？

1. 關聯式資料庫理論：關聯集合本質上是無序的，SQL 標準規定無 ORDER BY 時順序為「實作定義」。
2. 最佳化器目標：追求最低成本（I/O、CPU），而非特定順序。若非叢集索引較窄、統計資料顯示選擇率佳，最佳化器會選擇該索引。
3. 平行查詢：啟用平行處理時，多執行緒交錯輸出，順序更不可預測。
4. 快取與預讀：資料頁在緩衝區中的物理順序可能與邏輯順序不同。

常見誤區

最佳實務

1. 永遠在需要特定順序時明確加上 ORDER BY，哪怕「現在看起來是對的」。
2. 分頁查詢：OFFSET ... FETCH 或 ROW_NUMBER() 必須搭配確定性 ORDER BY。
3. 驗證順序：若歷史程式碼依賴隱含順序，請補上 ORDER BY 並加入回歸測試。
4. 效能考量：若 ORDER BY 導致排序成本過高，檢查是否有對應索引支援（避免 Sort 運算子）。

延伸閱讀

• SQL Server 執行計劃解讀指南
• 索引設計最佳實務：覆蓋索引與排序優化
• 平行查詢與 MAXDOP 設定對順序的影響