1. 使事務處理盡可能地短； 默認的TIL(Read Commited)下，開啟事務后，會話中的更新操作會持續占有排它鎖，直至事務提交或者回滾；使事務處理盡可能地短，減少持有資源的時間，盡快釋放資源...

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聯機叢書）在并發更新的可能性很小的系統中，處理“別人在您讀取數據后更改了數據”的偶然錯誤的開銷要比在讀取數據時始終鎖定行的開銷小得多。
     更好的做法是，避免使用游標。

 

(以后陸續補充。。。)