在数据库中使用事务有什么问题？

Question

从this post。一个明显的问题是可伸缩性/性能。交易使用会引发什么其他问题？

你可以说有两套问题，一个是长期运行的交易，一个是短期运行的交易？如果是的话，你会如何定义它们？

编辑：死锁是另一个问题，但数据不一致可能会更糟，具体取决于应用程序域。假设一个有交易价值的领域（银行，使用规范的例子），死锁的可能性更像是确保数据一致性的代价，而不是交易使用的问题，否则你会不同意？如果是这样，你会使用哪些其他解决方案来确保数据一致性无死锁？

Answer 1

它很大程度上取决于数据库中的事务性实现，也可能取决于您使用的事务隔离级别。我在这里假设“可重复读”或更高。长时间保持事务处理（即使没有任何修改的事务）也会强制数据库保留已删除或更新的经常更改的表的行（以防万一您决定读取它们），否则这些行可能会被丢弃。

此外，回滚事务可能非常昂贵。我知道在MySQL的InnoDB引擎中，回滚一个大事务可能需要比提交更长的FAR（我们已经看到回滚需要30分钟）。

另一个问题是与数据库连接状态有关。在分布式容错应用程序中，您永远不可能真正知道数据库连接处于什么状态。有状态的数据库连接无法轻松维护，因为它们可能随时都会失败（应用程序需要记住它的内容中间做它并重做它）。无状态的可以重新连接并且在没有（大多数情况下）断开状态的情况下重新发布（原子）命令。

Answer 2

事务的一个问题是，它可能（不太可能，但可能）在数据库中发生死锁。您必须了解您的数据库如何工作，锁定，​​交易等，以便调试这些有趣/令人沮丧的问题。

-Adam

Answer 3

我认为主要问题是在设计层面。我应用程序中的哪个级别或多个级别使用交易。

比如我可以：

• 存储过程中创建的交易，
• 使用数据访问API（ADO.NET）来控制交易
• 使用某种形式的隐式回退的应用程序中的高
• （通过DTC/COM +）的分布式事务。

在同一个应用程序中使用多于一个这些级别往往会导致性能和/或数据完整性问题。

Answer 4

即使不使用显式事务，也可能会出现死锁。首先，大多数关系数据库将对每个执行的语句应用一个隐式事务。

死锁主要是由于获取多个锁造成的，任何涉及获取多个锁的活动都会与任何其他活动（包括获取至少两个与第一个活动相同的锁）发生死锁。在数据库交易中，事实上，一些获得的锁可能比其他方式持有的时间要长 - 事务结束时。锁越长，死锁的机会就越大。这就是为什么长时间运行的事务比短时间事务更有可能发生死锁的原因。