最佳化交易處理

1. 使交易處理儘可能地短；

    預設的TIL(Read Commited)下，開啟事務後，會話中的更新操作會持續佔有排它鎖，直至事務提交或者復原；使交易處理儘可能地短，減少持有資源的時間，儘快釋放資源供其它會話使用；

2. 盡量避免在事務中進行讀操作；

    讀操作會對資源加共用鎖定，共用鎖定與排它鎖不相容，事務中的讀操作可能被阻塞，進而導致當前會話持有資源的同時被阻塞等待，會延長事務執行的事件，增加死結的幾率；
    可以把需要使用的資料先讀出來，然後再開啟事務；
    如果無法避免，可以嘗試在讀操作上加表提示with(nolock)。(注意：with nolock 可能導致髒讀)；

3. 不要再事務過程中等待與使用者的互動；

    同(1)；使用者可能喝茶或抽煙去了，回話就可能一直持有資源，別人如果要使用該資源的話，就沒法幹活了。

4. 謹慎使用無日誌操作

    有些操作會有一定的效能代價，例如SELECT….INTO在完成前會一直鎖定系統資料表；

5. 盡量使用低級的TIL

    預設是Read Commited；可以通過SET TRANSACTION ISOLATION LEVEL來修改。
    但要注意， 不同的隔離等級也可能導致副作用：(from SQL Server聯機叢書)

6. 盡量使交易處理中修改的資料最少

    使修改的資料儘可能少，減少鎖定的行數，從而減少事務之間的資源爭奪；
    建立合適的索引，降低鎖粒度，減少事務之間的資源爭奪；(當然建索引也有副作用，建得不好，會影響增刪改的效能)；
    考慮某個操作能否重做，如果可以重做且不會導致髒資料的話(或者髒資料不影響業務資料，允許髒資料存在)，可以將該操作搬到事務之外來做。譬如要物理大量刪除某批記錄及其對應的明細；表面上看，為了維護資料的一致性，要將這些操作放到事務裡面；但其實可以不用顯式使用事務：先刪明細，再刪主記錄；不顯式維護事務，如果刪除失敗，下次再刪一次就行。

7. 除非真的需要，否則不要使用隱含交易處理，即使使用也要小心監視。

    （form SQL Server聯機叢書）：為了防止並發問題和資源問題，應小心管理隱含交易。使用隱含交易時，COMMIT 或 ROLLBACK 後的下一個 Transact-SQL 陳述式會自動啟動一個新事務。這可能會在應用程式瀏覽資料時（甚至在需要使用者輸入時）開啟一個新事務。在完成保護資料修改所需的最後一個事務之後，應關閉隱性事務，直到再次需要使用事務來保護資料修改。此過程使 SQL Server 資料庫引擎 能夠在應用程式瀏覽資料以及擷取使用者輸入時使用自動認可模式。

    另外，啟用快照隔離等級後，儘管新事務不會控制鎖，但是長時間啟動並執行事務將阻止從 tempdb 中刪除舊版本。

8.  靈活地使用更低的遊標並發選項，例如開放式並發選項。

    （form SQL Server聯機叢書）在並發更新的可能性很小的系統中，處理“別人在您讀取資料後更改了資料”的偶然錯誤的開銷要比在讀取資料時始終鎖定行的開銷小得多。
     更好的做法是，避免使用遊標。

 

(以後陸續補充。。。)