Sql Firebird 2.0事务选择性能

在Firebird 2.0中，在SELECT命令上使用显式事务是否比使用隐式事务执行命令更快？

通常事务会增加一些开销。但是，如果在连接到Firebird时没有启动某些默认事务，则应小心。

所有SQL命令SELECT、INSERT、UPDATE等只能在某些事务中执行。您无法在未启动out事务之前运行命令。

Firebird无法在没有事务的情况下执行SQL命令

---

PS：如果您提交事务，而不是回滚事务，您将获得最佳性能结果。即使您只调用了SELECT并没有更改任何内容。

除了已经说过的内容之外，还要考虑到事务可以是：

读写 只读 对于SELECT，最好使用只读事务

---

PS：还有其他类型的事务，但这两种是本主题的重要事务。

显式和隐式事务是用于访问数据库的组件集的功能，而不是Firebird本身的功能。如前所述，Firebird总是在事务中做所有事情。这对您有几点影响：

使用隐式事务不会比使用显式事务更快，因为从Firebird的角度来看，事务就是事务，不管是谁启动的。 要获得最佳性能，有时需要对提交进行精细控制。虽然隐式事务不能比显式事务快，但显式事务可能更快，因为您可以控制StartTransactions和提交。虽然您通常希望在一个事务中对数据库执行所有更新，以便它们作为一个集合成功或失败，但有时您希望将操作拆分为多个组：如果需要批量插入许多记录，您可能希望每1000条左右提交一条记录。

---

根据我的经验，隐式事务往往默认为自动提交，因此它们应该更慢。您始终可以更改默认行为

但是我建议使用显式事务，因为如果它阻止了太多的事务，那么提交保留可能会使您更加痛苦。如果它这样做了，那么访问Firebird的速度会大大减慢，因为它会遍历所有被阻止/阻止的事务，以确定数据的正确值

这里有一些讨论

---

这让人困惑，因为我正在使用.net Firebird提供程序，它有一个FBCommand构造函数，将事务作为参数，而另一个构造函数则不这样做。此外，在通过调用dbcmd.BeginTransaction在FBConnection实例中显式启动事务之前，不会启动事务。我已经测试了插入的速度，并且在使用事务时看到了与不使用事务参数的FBCommand相比的显著改进。我编辑了问题以反映FBCommand的隐式和显式事务模型。我已经测试了插入的速度，并且在使用事务时看到了显著改进，与使用不带事务参数的FBCommand相比。在后一种情况下，INSERT语句的每次执行都涉及到内部事务的隐式开始和结束。这就是为什么它需要更长的时间。Multam，Cosmine，si+1 pentru sfat。