来自this post。一个明显的问题是可扩展性/性能。交易使用还会引发哪些其他问题？
您能说有两组问题，一组针对长期运行的事务，一组针对短期运行的事务吗？如果是，你会如何定义它们？
编辑：死锁是另一个问题，但数据不一致可能会更糟，具体取决于应用程序域。假设一个值得交易的领域（银行，使用规范的例子），死锁的可能性更像是为确保数据一致性而付出的代价，而不是交易使用的问题，或者你会不同意？如果是这样，您将使用哪些其他解决方案来确保无死锁的数据一致性？
【问题讨论】：
标签： sql transactions deadlock
这在很大程度上取决于数据库中的事务实现，也可能取决于您使用的事务隔离级别。我在这里假设“可重复读取”或更高。长时间保持事务打开（即使是没有修改任何内容的事务）会强制数据库保留经常更改的表的已删除或更新行（以防万一您决定读取它们），否则这些表可能会被丢弃。
此外，回滚交易可能非常昂贵。我知道在 MySQL 的 InnoDB 引擎中，回滚一个大事务可能需要比提交它更长的时间（我们已经看到回滚需要 30 分钟）。
另一个问题与数据库连接状态有关。在分布式容错应用程序中，您永远无法真正知道数据库连接处于什么状态。有状态的数据库连接不容易维护，因为它们随时可能失败（应用程序需要记住它处于什么状态中间做它并重做它）。无状态的可以重新连接并重新发出（原子）命令，而不会（在大多数情况下）破坏状态。
【讨论】：
即使不使用显式事务，您也可能会出现死锁。一方面，大多数关系数据库都会对您执行的每条语句应用一个隐式事务。
死锁基本上是由获取多个锁引起的，任何涉及获取多个锁的活动都可能与涉及获取至少两个与第一个活动相同的锁的任何其他活动发生死锁。在数据库事务中，某些获取的锁可能会比其他情况下持有的时间更长——事实上，直到事务结束。持有的锁越长，发生死锁的机会就越大。这就是为什么一个运行时间较长的事务比一个较短的事务更有可能发生死锁。
【讨论】：
事务的一个问题是有可能（不太可能，但可能）在数据库中出现死锁。为了调试这些有趣/令人沮丧的问题，您必须了解数据库的工作原理、锁定、事务等。
-亚当
【讨论】：
我认为主要问题在于设计层面。我在我的应用程序中的哪个或多个级别使用事务。
例如我可以：
在同一应用程序中使用这些级别中的一个以上通常似乎会产生性能和/或数据完整性问题。
【讨论】：