1. 使事務處理盡可能地短；
預設的til(read commited)下，開啟事務後，會話中的更新操作會持續占有排它鎖，直至事務提交或者回滾；使事務處理盡可能地短，減少持有資源的時間，盡快釋放資源供其它會話使用；
2. 盡量避免在事務中進行讀操作；
讀操作會對資源加共享鎖，共享鎖與排它鎖不相容，事務中的讀操作可能被阻塞，進而導致當前會話持有資源的同時被阻塞等待，會延長事務執行的事件，增加死鎖的機率；
可以把需要使用的資料先讀出來，然後再開啟事務；
如果無法避免，可以嘗試在讀操作上加表提示with(nolock)。(注意：with nolock 可能導致髒讀)；
3. 不要再事務過程中等待與使用者的互動；
同(1)；使用者可能喝茶或抽菸去了，回話就可能一直持有資源，別人如果要使用該資源的話，就沒法幹活了。
4. 謹慎使用無日誌操作
有些操作會有一定的效能代價，例如select….into在完成前會一直鎖定系統表；
5. 盡量使用低階的til
6. 盡量使事務處理中修改的資料最少
使修改的資料盡可能少，減少鎖定的行數，從而減少事務之間的資源爭奪；
建立合適的索引，降低鎖粒度，減少事務之間的資源爭奪；(當然建索引也有***，建得不好，會影響增刪改的效能)；
考慮某個操作能否重做，如果可以重做且不會導致髒資料的話(或者髒資料不影響業務資料，允許髒資料存在)，可以將該操作搬到事務之外來做。譬如要物理批量刪除某批記錄及其對應的明細；表面上看，為了維護資料的一致性，要將這些操作放到事務裡面；但其實可以不用顯式使用事務：先刪明細，再刪主記錄；不顯式維護事務，如果刪除失敗，下次再刪一次就行。
7. 除非真的需要，否則不要使用隱式事務處理，即使使用也要小心監視。
（form sql server聯機叢書）：為了防止併發問題和資源問題，應小心管理隱式事務。使用隱式事務時，commit 或 rollback 後的下乙個 transact-sql 語句會自動啟動乙個新事務。這可能會在應用程式瀏覽資料時（甚至在需要使用者輸入時）開啟乙個新事務。在完成保護資料修改所需的最後乙個事務之後，應關閉隱性事務，直到再次需要使用事務來保護資料修改。此過程使 sql server 資料庫引擎 能夠在應用程式瀏覽資料以及獲取使用者輸入時使用自動提交模式。
另外，啟用快照隔離級別後，儘管新事務不會控制鎖，但是長時間執行的事務將阻止從 tempdb 中刪除舊版本。
8. 靈活地使用更低的游標併發選項，例如開放式併發選項。
（form sql server聯機叢書）在併發更新的可能性很小的系統中，處理「別人在您讀取資料後更改了資料」的偶然錯誤的開銷要比在讀取資料時始終鎖定行的開銷小得多。
更好的做法是，避免使用游標。
(以後陸續補充。。。)
優化事務處理
1.使事務處理盡可能地短 預設的til read commited 下，開啟事務後，會話中的更新操作會持續占有排它鎖，直至事務提交或者回滾 使事務處理盡可能地短，減少持有資源的時間，盡快釋放資源供其它會話使用 2.盡量避免在事務中進行讀操作 讀操作會對資源加共享鎖，共享鎖與排它鎖不相容，事務中的讀操...
PB事務處理
1 資料視窗更新，只要dberror有錯誤，而事先沒有做過任何commit工作，那麼rollback可以回滾到上次commit位置，即上次commit後所有的資料將被回滾。2 如果是直接寫入sql語句，只要資料庫出現錯誤，那麼rollback可以回滾到上次commit的位置，即上次commit後所有...
MySQL事務處理
start transaction,commit和rollback語法 start transaction begin work commit work and no chain no release rollback work and no chain no release set autocom...