撰寫有效率的交易
儘可能讓交易越短越好相當重要。開始交易時，資料庫管理系統 (DBMS) 在交易結束之前必須保存許多資源，以保護交易的不可部份完成特性、一致性、隔離和持久性 (ACID) 屬性。如果已修改資料，必須以獨佔鎖定 (防止其他交易讀取資料列) 保護修改的資料列，並且在認可或回復交易之前必須保持獨佔鎖定。視交易隔離等級的設定而定，SELECT 陳述式可能會取得在認可或回復交易之前必須保持的鎖定。尤其是在擁有許多使用者的系統上，必須盡可能讓交易越短越好，以降低鎖定爭用並行連接之間的資源。在少數使用者的情況下，沒有效率的長時間執行交易不會造成問題，但在擁有上千個使用者的系統中則無法忍受這種交易。
撰寫指引
以下為撰寫有效交易的指引：
交易期間毋需使用者輸入。
啟動交易前，先取得必要的使用者所有輸入內容。如果交易期間需要額外的使用者輸入，則復原目前的交易，並於使用者提供輸入之後重新啟動交易。即使使用者立即回應，人類的反應時間還是比電腦的速度慢很多。交易佔用所有資源的時間非常久，這是造成封鎖問題的潛在因素。如果使用者並未回應，交易便維持作用中，並鎖定重要的資源直到使用者回應為止，這種情形可能會維持數分鐘，或甚至幾小時。
如果位在全部皆可行，不要在瀏覽資料時開啟交易。
交易應該等到所有的初步資料分析完成之後再啟動。
盡可能讓交易越短越好。
在您知道必須進行的修改之後，請啟動交易、執行修改陳述式，然後立即進行認可或回復。除非必要，否則請勿開啟交易。
若要減少封鎖問題，請考慮使用以資料列版本控制為基礎的隔離層級來進行唯讀查詢。如需詳細資訊，請參閱＜使用資料列版本控制式的隔離等級＞。
善用較低的交易隔離等級。
許多應用程式可輕易地撰寫成使用讀取 - 認可式的交易隔離等級。並非所有交易都需要可序列化的交易隔離等級。
善用較低的資料指標並行選項，例如樂觀並行 (Optimistic Concurrency) 選項。
在並行更新的可能性較低的系統中，處理偶發的「有人在您讀取資料之後變更過資料」錯誤的負擔，可能比讀取時一直鎖定資料列的負擔更低。
在交易中儘可能存取最少的資料量。
這會減少鎖定的資料列數量，因而降低了交易之間的競爭。
避免並行與資源問題
若要避免並行與資源的問題，請小心管理隱含交易。使用隱含交易時，COMMIT 或 ROLLBACK 之後的下一個 Transact-SQL 陳述式會自動啟動一筆新的交易。這可能造成交易在應用程式瀏覽資料時，或甚至在需要使用者輸入時被開啟。保護資料修改所需的最後一筆交易完成之後，請關閉隱含交易，直到交易再度需要保護資料修改為止。這個程序讓「SQL Server Database Engine」在應用程式瀏覽資料及取得使用者輸入時使用自動認可模式。
此外，啟用快照隔離等級時，雖然新交易不會佔用鎖定，但長時間執行的交易仍會阻礙從 tempdb 移除舊版本。