Firebird 2.0事務SELECT性能

3

所有的SQL命令（SELECT，INSERT，UPDATE等）只能在一些事務中執行。在事務之前，您無法運行一個命令。

2009-10-29 16:46:11

+0

這是令人困惑，因爲我與.NET火鳥供應商合作，它有一個FBCommand構造函數交易爲參數和另一個不包含的構造函數。此外，通過調用* dbcmd.BeginTransaction（）*，在FBConnection實例中顯式執行事務之前，事務不會啓動。我測試了INSERT的速度，並且在使用事務時看到了顯着的改進，與使用沒有* transaction *參數的FBCommand相比。 – luvieere 2009-10-29 17:30:56

+0

我編輯了問題以反映FBCommand的隱式和顯式事務模型。 – luvieere 2009-10-30 17:14:22

+2

「我測試了INSERT的速度，並且在使用事務時看到了顯着的改進，與使用沒有事務參數的FBCommand相比。」在後一種情況下，INSERT語句的每次執行都涉及內部事務的隱式開始和結束。這就是爲什麼它需要更長的時間。 – 2009-11-12 08:50:05

0

通常事務會增加一些開銷。但是，如果在連接到Firebird時沒有啓動一些默認事務，則應該小心。

來源

2009-10-29 16:07:33 smok1

1

如果沒有事務，Firebird將無法執行SQL命令。 PS：如果您提交事務而不是回滾事務，則會獲得最佳性能結果。即使你只調用了SELECT，也沒有改變。

來源

2009-10-30 15:28:13

1

除了什麼已經說了，考慮到該交易可以是：

讀寫
只讀

對於SELECT這將是最好使用只讀事務

PS：還有其他類型的事務，但這兩個是這個主題的重要內容。

來源

2010-05-16 08:49:04

2

顯式和隱式事務是用於訪問數據庫的組件集的一個功能，而不是Firebird本身的功能。如前所述，Firebird 總是完成交易中的所有內容。這對你有幾點影響：

使用「隱式」事務不能比使用「顯式」事務更快，因爲從Firebird的角度來看，事務是事務，並不重要誰開始了它。
獲得最佳性能有時需要對「提交」進行良好控制。雖然「隱式」事務不可能比「顯式」事務更快，但顯式可能會更快，因爲您可以控制您的StartTransactions和Commits。雖然您通常希望在一個事務中對數據庫執行所有更新（因此它們全都成功或失敗），但有時您希望將操作拆分爲多個組：如果您需要批量插入多條記錄，則可能需要每1000條記錄提交一份。

來源

2010-05-21 06:04:03

+0

Multam，Cosmine，si +1 pentru sfat。 – luvieere 2010-05-21 06:52:44

0

根據我的經驗，隱式事務傾向於默認爲自動提交保留，因此它們應該更慢。您始終可以更改默認行爲。

但我會建議使用明確的交易作爲提交保留可能會導致你的悲傷進一步下降，如果它阻止了太多的交易。如果確實如此，那麼訪問Firebird的速度可能會大幅減慢，因爲它會遍歷所有阻塞/阻塞事務以確定數據的正確值。

下面是一些關於它的討論

http://forums.devshed.com/firebird-sql-development-61/difference-active-transaction-863103.html

http://www.slideshare.net/ibsurgeon/3-how-transactionswork

來源

2015-08-18 14:08:39