在數據庫中使用事務有什麼問題？

Question

從this post。一個明顯的問題是可伸縮性/性能。交易使用會引發什麼其他問題？

你可以說有兩套問題，一個是長期運行的交易，一個是短期運行的交易？如果是的話，你會如何定義它們？

編輯：死鎖是另一個問題，但數據不一致可能會更糟，具體取決於應用程序域。假設一個有交易價值的領域（銀行，使用規範的例子），死鎖的可能性更像是確保數據一致性的代價，而不是交易使用的問題，否則你會不同意？如果是這樣，你會使用哪些其他解決方案來確保數據一致性無死鎖？

Answer 1

它很大程度上取決於數據庫中的事務性實現，也可能取決於您使用的事務隔離級別。我在這裏假設「可重複讀」或更高。長時間保持事務處理（即使沒有任何修改的事務）也會強制數據庫保留已刪除或更新的經常更改的表的行（以防萬一您決定讀取它們），否則這些行可能會被丟棄。

此外，回滾事務可能非常昂貴。我知道在MySQL的InnoDB引擎中，回滾一個大事務可能需要比提交更長的FAR（我們已經看到回滾需要30分鐘）。

另一個問題是與數據庫連接狀態有關。在分佈式容錯應用程序中，您永遠不可能真正知道數據庫連接處於什麼狀態。有狀態的數據庫連接無法輕鬆維護，因爲它們可能隨時都會失敗（應用程序需要記住它的內容中間做它並重做它）。無狀態的可以重新連接並且在沒有（大多數情況下）斷開狀態的情況下重新發布（原子）命令。

Answer 2

事務的一個問題是，它可能（不太可能，但可能）在數據庫中發生死鎖。您必須瞭解您的數據庫如何工作，鎖定，​​交易等，以便調試這些有趣/令人沮喪的問題。

-Adam

Answer 3

我認爲主要問題是在設計層面。我應用程序中的哪個級別或多個級別使用交易。

比如我可以：

• 存儲過程中創建的交易，
• 使用數據訪問API（ADO.NET）來控制交易
• 使用某種形式的隱式回退的應用程序中的高
• （通過DTC/COM +）的分佈式事務。

在同一個應用程序中使用多於一個這些級別往往會導致性能和/或數據完整性問題。

Answer 4

即使不使用顯式事務，也可能會出現死鎖。首先，大多數關係數據庫將對每個執行的語句應用一個隱式事務。

死鎖主要是由於獲取多個鎖造成的，任何涉及獲取多個鎖的活動都會與任何其他活動（包括獲取至少兩個與第一個活動相同的鎖）發生死鎖。在數據庫交易中，事實上，一些獲得的鎖可能比其他方式持有的時間要長 - 事務結束時。鎖越長，死鎖的機會就越大。這就是爲什麼長時間運行的事務比短時間事務更有可能發生死鎖的原因。