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

Question

来自this post。一个明显的问题是可伸缩性/性能。事务使用的其他问题是什么？

您是否可以说有两组问题，一组用于长时间运行的事务，另一组用于短时间运行的事务？如果是，你会如何定义它们？

编辑:死锁是另一个问题，但数据不一致可能会更严重，这取决于应用程序域。假设一个有事务价值的域(银行，使用规范的例子)，死锁可能性更像是为了确保数据一致性而支付的成本，而不是事务使用的问题，否则您会不同意吗？如果是这样，您会使用哪些其他解决方案来确保无死锁的数据一致性？

Answer 1

这在很大程度上取决于数据库中的事务实现，也可能取决于您使用的事务隔离级别。我假设这里是“可重复读取”或更高级别的。长时间持有打开的事务(即使是未修改任何内容的事务)会迫使数据库保留频繁变化的表的已删除或更新的行(以防您决定读取它们)，否则这些行可能会被丢弃。

此外，回滚事务可能会非常昂贵。我知道在MySQL的InnoDB引擎中，回滚一个大事务可能比提交它花费的时间要长得多(我们已经看到回滚需要30分钟)。

另一个问题是数据库连接状态。在分布式容错应用程序中，您永远无法真正知道数据库连接处于什么状态。有状态的数据库连接不容易维护，因为它们随时都可能失败(应用程序需要记住它在做这件事的过程中是什么，并重新做这件事)。无状态的可以重新连接并重新发出(原子)命令，而不会(在大多数情况下)中断状态。

Answer 2

即使不使用显式事务，您也可以获得死锁。首先，大多数关系数据库将对您执行的每条语句应用隐式事务。

死锁从根本上是由获取多个锁引起的，任何涉及获取多个锁的活动都可能与涉及获取至少两个与第一个活动相同的锁的任何其他活动发生死锁。在数据库事务中，一些获取的锁的持有时间可能比它们本来持有的时间更长--事实上，直到事务结束。锁持有的时间越长，发生死锁的可能性就越大。这就是运行时间较长的事务比运行时间较短的事务更有可能发生死锁的原因。

Answer 3

事务的一个问题是有可能(不太可能，但有可能)在数据库中出现死锁。你必须了解你的数据库是如何工作的，锁，事务等，以便调试这些有趣/令人沮丧的问题。

-Adam