交易是否會給數據庫增加開銷？

是否會在我們的應用程序中爲每個服務方法添加DB 事務而增加開銷？交易是否會給數據庫增加開銷？

我們目前只使用數據庫事務，這是明確的/顯而易見的必要條件。我最近建議交易圍繞所有服務方法，但其他一些開發商問謹慎的問題：會增加開銷嗎？

我的感覺不是 - 自動提交與數據庫透視圖中的事務相同。但這是否準確？

DB：MySQL的

來源

2012-02-14 David Parks

你是對的，有自動提交每個語句被包裹在交易。如果您的服務方法正在執行多個sql語句，那麼將它們包裝到一個事務中將會很好。看看this答案瞭解更多詳情，here是一個很好的博客文章。

爲了回答你的問題，是的，事務確實增加了性能開銷，但在你的具體情況下，除非在服務方法中有很長的運行語句，否則你不會注意到這種差異，因爲你已經啓用了自動提交功能，參與交易的表的鎖定時間更長。如果您只是將多個語句包裝在一個事務中，您將得到一個事務（而不是針對每個單獨語句的事務），如指向here（「啓用自動提交的會話可以通過顯式啓動它來執行多語句事務START TRANSACTION或BEGIN語句，並以COMMIT或ROLLBACK語句結束它「），並且您將在服務方法級別實現原子性...

最後，我會用您的解決方案，如果這樣做有道理在服務方法的水平（這是我認爲要實現）實現原子性的觀點，但也有+和 - 對性能的影響，這取決於您的查詢，請求/秒等......

來源

2012-02-14 04:22:14

是的，他們可以增加開銷。將交易隔離開來所需的額外「簿記」可能會變得很重要，特別是如果交易長期處於開放狀態。

來源

2012-02-14 04:25:43 duskwuff

簡而言之，它取決於您的表格類型。如果您使用MyISAM，默認情況下，沒有真正的交易，所以應該對性能沒有影響。

但是無論如何，你應該使用它們。沒有交易，就沒有工作分界。如果你升級到InnoDB或像PostgreSQL這樣的真正的數據庫，那麼你仍然希望把這些事務添加到你的服務方法中，所以你現在可以習慣於這樣做，而不用花費任何東西。

此外，您應該已經在使用事務性存儲。如果當前服務方法失敗，你如何清理？如果向數據庫寫入一些信息，然後服務方法拋出異常，那麼如何清除那些不完整或錯誤的信息？如果您使用的是交易，您不必 - 數據庫會爲您丟棄回滾的數據。或者，如果我通過一種方法的一半，而另一個請求進來並發現我的一半寫入的數據，你會怎麼做？當它尋找另一半還沒到的時候它會炸燬嗎？一個事務型數據存儲處理這個你：你的交易將彼此隔離，讓其他人可以看到一個部分寫入事務。

與數據庫中的所有內容一樣，唯一確定的答案將來自測試真實數據和實際負載。我建議你總是這麼做，不管你懷疑什麼，因爲當涉及到數據庫時，當數據量大時，數據庫中的代碼路徑會變得非常不同。但我強烈懷疑，即使使用InnoDB，使用交易的成本也不是很高。畢竟，這些系統每天都被大大小小的組織持續大量使用，這些組織依賴於交易表現良好。 MVCC增加了很少的開銷。好處是巨大的，成本低，使用它們！

來源

2012-02-14 04:33:35

我們使用的是InnoDB，我的論點不會丟失，我只需要找到一些證據證明這不會導致性能問題。測試也許（但這是很多工作）。我更願意從已經花時間處理問題的人那裏獲得一篇好文章或博客。 – 2012-02-15 10:53:27

就像我說過的，你應該依賴的唯一證據就是你自己的實驗證據。 – 2012-02-15 13:54:16

交易是否會給數據庫增加開銷？

回答

相關問題