[SQL Server] 關於sql server的一些問題

不要使用遊標

　　不知你是否知道每執行一次FETCH就等於執行一次SELECT命令？這意味著如果你的游標有10000條記錄，它將執行10000次SELECT！

我曾經用T-SQL重寫了一個基於游標的預存程序，那個表只有100,000條記錄，原來的預存程序用了40分鐘才執行完畢，而新的預存程序只用了10秒鐘。在這裡，我想你應該可以看到一個不稱職的程式員究竟在幹了什麼！！！

我們可以寫一個小程式來取得和處理資料並且更新資料庫，這樣做有時會更有效。記住：對於迴圈，T-SQL無能為力。

 不要使用SELECT
*

這點不太容易做到，我太瞭解了，因為我自己就經常這樣幹。可是，如果在SELECT中指定你所需要的列，那將會帶來以下的好處：

　　1.  減少記憶體耗費和網路的頻寬

　　2. 你可以得到更安全的設計

　　3. 給查詢最佳化工具機會從索引讀取所有需要的列

使用事務

請使用事務，特別是當查詢比較耗時。如果系統出現問題，這樣做會救你一命的。一般有些經驗的程式員都有體會-----你經常會碰到一些不可預料的情況會導致預存程序崩潰。

小心死結

按照一定的次序來訪問你的表。如果你先鎖住表A，再鎖住表B，那麼在所有的預存程序中都要按照這個順序來鎖定它們。如果你（不經意的）某個預存程序中先鎖定表B，再鎖定表A，這可能就會導致一個死結。如果鎖定順序沒有被預先詳細的設計好，死結是不太容易被發現的。

在程式編碼時使用大資料量的資料庫

程式員在開發中使用的測試資料庫一般資料量都不大，可經常的是終端使用者的資料量都很大。我們通常的做法是不對的，原因很簡單：現在硬碟不是很貴，可為什麼效能問題卻要等到已經無可挽回的時候才被注意呢？

不要使用INSERT匯入大批的資料

請不要這樣做，除非那是必須的。使用UTS或者BCP，這樣你可以一舉而兼得靈活性和速度。

注意逾時問題

查詢資料庫時，一般資料庫的預設都比較小，比如15秒或者30秒。而有些查詢已耗用時間要比這長，特別是當資料庫的資料量不斷變大時。

在細節表中插入紀錄時，不要在主表執行SELECT
MAX(ID)

這是一個普遍的錯誤，當兩個使用者在同一時間插入資料時，這會導致錯誤。你可以使用SCOPE_IDENTITY，IDENT_CURRENT和@@IDENTITY。如果可能，不要使用@@IDENTITY，因為在有觸發器的情況下，它會引起一些問題（詳見這裡的討論）。

避免將列設為NULLable

如果可能的話，你應該避免將列設為NULLable。系統會為NULLable列的每一行分配一個額外的位元組，查詢時會帶來更多的系統開銷。另外，將列設為NULLable使編碼變得複雜，因為每一次訪問這些列時都必須先進行檢查。

我並不是說NULLS是麻煩的根源，儘管有些人這樣認為。我認為如果你的商務規則中允許“空資料”，那麼，將列設為NULLable有時會發揮很好的作用

盡量不要使用TEXT資料類型

除非你使用TEXT處理一個很大的資料，否則不要使用它。因為它不易於查詢，速度慢，用的不好還會浪費大量的空間。一般的，VARCHAR可以更好的處理你的資料。

盡量不要使用暫存資料表

盡量不要使用暫存資料表，除非你必須這樣做。一般使用子查詢可以代替暫存資料表。使用暫存資料表會帶來系統開銷，如果你是用COM+進行編程，它還會給你帶來很大的麻煩，因為COM+使用資料庫連接池而暫存資料表卻自始至終都存在。SQL
Server提供了一些替代方案，比如Table資料類型。

學會分析查詢

SQL
Server查詢分析器是你的好夥伴，通過它你可以瞭解查詢和索引是如何影響效能的。

使用參照完整性

定義主健、唯一性限制式和外鍵，這樣做可以節約大量的時間。