SQL Server 查詢設計必避的 10 大常見錯誤

查詢設計品質直接決定系統效能與維護成本。本文整理 10 個資料庫開發人員常犯的錯誤，並提供具體改善建議，助你寫出高效、可維護的 T-SQL 程式碼。

錯誤 1：資料模型未考量存取模式

現象：設計資料表時只想正規化，未考慮實際查詢如何 JOIN，導致執行計畫充滿不必要的連接、索引無法有效運作。

改善：先列出核心查詢案例，再反向設計資料模型。適度反正規化、加入計算欄位或摘要表，換取查詢效能。

錯誤 2：盲目迷信集合導向或游標

現象：聽說「游標慢」就全盤拒絕，或習慣用游標處理逐筆邏輯。

改善：集合導向適合批次資料操作；游標/WHILE 迴圈適合複雜逐筆業務邏輯、動態 SQL 組裝、呼叫外部 API。依場景選擇，而非教條。

錯誤 3：停留在舊版寫法，忽略新功能

現象：SQL Server 2005+ 提供 TRY...CATCH、CTE、ROW_NUMBER()、PIVOT/UNPIVOT、CLR 整合 等功能，仍用舊寫法。

改善：採用 TRY...CATCH 統一錯誤處理；用 CTE 處理遞迴查詢；用視窗函數簡化分頁與排序邏輯。

錯誤 4：部署前未檢視執行計畫

現象：測試環境資料量小，上線後才發現全表掃描、索引遺漏、統計資料過期。

改善：養成習慣——Ctrl+L 顯示預估執行計畫，Ctrl+M 顯示實際執行計畫。關注：索引搜尋 vs 掃描、排序運算子、資料列估算偏差。

錯誤 5：濫用 SELECT *

現象：圖省事寫 SELECT *，資料表結構變更時應用程式崩潰，或傳輸不必要欄位浪費網路/記憶體。

改善：永遠明確列出欄位名稱。使用 sp_help 或 SSMS「腳本產生器」快速取得欄位清單。

錯誤 6：程式碼缺乏註解

現象：複雜邏輯無說明，後續維護者 (包含未來的自己) 需花費數倍時間理解意圖。

改善：註解為什麼這樣寫 (業務規則、效能考量、暫時性妥協)，而非做什麼 (程式碼已說明)。

錯誤 7：測試資料量與生產環境脫節

現象：開發機幾千筆資料跑得飛快，生產機百萬筆資料加上索引碎片、參數嗅探、鎖競爭，查詢超時。

改善：測試環境必須有：生產級資料量、碎片化索引、真實統計資料、並發負載模擬。

錯誤 8：把過濾邏輯推給應用層

現象：SELECT * FROM Orders 回傳百萬筆，再由中介層/前端過濾。

改善：資料庫就是為了高效過濾而生。盡早套用 WHERE、TOP、分頁，只傳輸必要資料。

錯誤 9：過度嵌套檢視表

現象：View 查 View，查詢優化器難以展開最佳化，統計資料傳遞失真，效能雪崩。

改善：限制 View 巢狀深度 (建議 ≤ 2)；複雜邏輯改用預存程序 + 參數化；考慮索引檢視表 (Indexed View) 物化結果。

錯誤 10：不記錄與分享經驗教訓

現象：踩過的坑沒留下文件，團隊成員重複犯錯。

改善：建立團隊「查詢設計指南」文件，記錄：命名慣例、索引策略、禁用語法、效能調優清單、踩坑案例。

總結：建立個人/團隊程式碼檢核清單

將上述 10 項轉化為 Code Review 清單，每次提交前自我檢視。長期累積，查詢品質將顯著提升，系統穩定度與團隊效率同步改善。