SQL Server常見的需要避免的查詢設計錯誤：

1、如果你在構建數據模型的時候沒有考慮到數據的訪問方式，將會導致難以處理的查詢。你可能會用到根本不必要的JOIN增加代碼，損害性能。
假如你要糾正這個問題，可以考慮一下需要訪問數據的查詢。如果查詢在這個處理階段不是很清晰，那么將來在寫代碼的時候就會更困難。很有可能是數據庫設計過于復雜，可以通過簡化來改善查詢的性能。

與此相關，如果你是個喜歡直觀的人，那么就打印出數據模型，或者在你選擇數據建模工具的時候查看一下在線的模型。這可以改善你的代碼時間和精確性。

2、傳統的說法是，對所有的數據庫訪問都使用基于集合的邏輯。一般來說，我同意這是最好的經驗之一。當基于集合的邏輯是正確的選擇的時候，卻使用了指針，可能會對性能產生很大的損害。SQL Server的設計是使用基于集合的邏輯，并且在大多數處理中應該使用它。

事分兩面，另一面就是指針的例子。在這種情況下，指針邏輯勝過基于集合的邏輯。從這個信息引申出來的結論就是，判斷你要執行的處理的類型，選擇最適合需要的技巧。

3、SQL Server 2005為你的查詢提供了一整套新的機會。所以使用老的辦法可能仍然會起作用，但是也是時候去考慮一下最新的選擇了。TRY…CATCH錯誤處理方法是你最先應該使用在代碼中的技巧之一。此外還要考慮的是對層次進行處理的時候，可以用到通用表壓縮;最后一項考慮是擴展關系型數據庫引擎的功能:通用語言運行時(CLR)。這三項技術都在極大程度上改變了你使用SQL Server工作的方式，而它們只是冰山一角。

4、檢查你的代碼，然后安排一個時間進行同樣的查看，這是在部署代碼之前必須要做的事情。檢查你的代碼，明確查詢計劃，是確保使用了合適的索引，并且查詢會像你期望的那樣運行的重要保障。

5、輸入SELECT *語句，想著表永遠不會改變，這是一個經典的查詢設計錯誤。即使在最簡單的解決方案中，表的改變也是不可避免的，你需要查看代碼確保沒有包含一個額外的字段。或者，更糟糕的是，你必須等待應用程序崩潰，然后修正這些問題。最好的實踐方案只是在你的查詢中包含進來你需要的那些字段，然后必要的話就修改它們。不要把你的時間浪費在四處冒煙的模式中徹查代碼。

6、不幸的是，我見過的大多數代碼都很少或者根本沒有注釋。所以進行更改是一件令人畏懼的任務，即使是對那些最初開發了這個應用程序的開發人員和/或數據庫管理員。注釋你的代碼真的是一個快速并且不痛苦的過程，對于未來的開發人員以安全和省時的方式理解和修改代碼來說，這是至關重要的。

7、很少有開發人員和數據庫管理員會喜歡簡單的測試，他們也不喜歡在發布代碼到產品環境之前進行嚴格的測試。并且，開發環境通常在硬件和數據量上都達不到產品環境的規模。就是說，簡單的查詢在幾百個或者甚至是幾千個記錄上都可以工作良好，但是在產品環境中就不是這樣了。對于你的查詢沒有別的更好的準備辦法了，只有在測試環境中對含有碎片的表中幾百萬條數據進行測試，以此來確保查詢會按照你的期望運行。

8、輸入SELECT語句，沒有包含WHERE子句，期望中間層或者前端以比SQL Server更加有效的方式來處理得到的數據，這是個很糟糕的主意。SQL Server就是設計用來處理查詢，并且將其執行得非常高效的。將大量的數據移動只會讓被洪水包圍的系統和網絡陷入困境。一定要盡可能地過濾你的數據，避免對性能產生影響。

9、視圖可以滿足你簡化復雜查詢中的代碼的需求。它們通常用來幫助有權利的用戶查詢數據庫。不幸的是，太多的好事情也會嚴重影響性能。視圖就是一個簡單的SELECT語句，視圖的SELECT語句必須在每次你輸入SELECT語句的時候再次輸入。限制視圖的使用，防止它們查詢其他視圖?；蛘撸瑯嫿ㄒ粋€存儲過程來查詢數據，并且傳遞給它需要的參數來滿足應用程序或者用戶的需求。