共用方式為


撰寫有效率的交易

儘可能讓交易越短越好相當重要。開始交易時,資料庫管理系統 (DBMS) 在交易結束之前必須保存許多資源,以保護交易的不可部份完成特性、一致性、隔離和持久性 (ACID) 屬性。如果已修改資料,必須以獨佔鎖定 (防止其他交易讀取資料列) 保護修改的資料列,並且在認可或回復交易之前必須保持獨佔鎖定。視交易隔離等級的設定而定,SELECT 陳述式可能會取得在認可或回復交易之前必須保持的鎖定。尤其是在擁有許多使用者的系統上,必須盡可能讓交易越短越好,以降低鎖定爭用並行連接之間的資源。在少數使用者的情況下,沒有效率的長時間執行交易不會造成問題,但在擁有上千個使用者的系統中則無法忍受這種交易。

撰寫指引

以下為撰寫有效交易的指引:

  • 交易期間毋需使用者輸入。

    啟動交易前,先取得必要的使用者所有輸入內容。如果交易期間需要額外的使用者輸入,則復原目前的交易,並於使用者提供輸入之後重新啟動交易。即使使用者立即回應,人類的反應時間還是比電腦的速度慢很多。交易佔用所有資源的時間非常久,這是造成封鎖問題的潛在因素。如果使用者並未回應,交易便維持作用中,並鎖定重要的資源直到使用者回應為止,這種情形可能會維持數分鐘,或甚至幾小時。

  • 如果位在全部皆可行,不要在瀏覽資料時開啟交易。

    交易應該等到所有的初步資料分析完成之後再啟動。

  • 盡可能讓交易越短越好。

    在您知道必須進行的修改之後,請啟動交易、執行修改陳述式,然後立即進行認可或回復。除非必要,否則請勿開啟交易。

  • 若要減少封鎖問題,請考慮使用以資料列版本控制為基礎的隔離層級來進行唯讀查詢。如需詳細資訊,請參閱<使用資料列版本控制式的隔離等級>。

  • 善用較低的交易隔離等級。

    許多應用程式可輕易地撰寫成使用讀取 - 認可式的交易隔離等級。並非所有交易都需要可序列化的交易隔離等級。

  • 善用較低的資料指標並行選項,例如樂觀並行 (Optimistic Concurrency) 選項。

    在並行更新的可能性較低的系統中,處理偶發的「有人在您讀取資料之後變更過資料」錯誤的負擔,可能比讀取時一直鎖定資料列的負擔更低。

  • 在交易中儘可能存取最少的資料量。

    這會減少鎖定的資料列數量,因而降低了交易之間的競爭。

避免並行與資源問題

若要避免並行與資源的問題,請小心管理隱含交易。使用隱含交易時,COMMIT 或 ROLLBACK 之後的下一個 Transact-SQL 陳述式會自動啟動一筆新的交易。這可能造成交易在應用程式瀏覽資料時,或甚至在需要使用者輸入時被開啟。保護資料修改所需的最後一筆交易完成之後,請關閉隱含交易,直到交易再度需要保護資料修改為止。這個程序讓「SQL Server Database Engine」在應用程式瀏覽資料及取得使用者輸入時使用自動認可模式。

此外,啟用快照隔離等級時,雖然新交易不會佔用鎖定,但長時間執行的交易仍會阻礙從 tempdb 移除舊版本。

請參閱

概念