在数据库中使用事务会遇到哪些问题？

Question

从 这个帖子. 。一个明显的问题是可扩展性/性能。交易使用还会引发哪些其他问题？

您是否可以说存在两组问题，一组针对长时间运行的事务，一组针对短期运行的事务？如果是，你会如何定义它们？

编辑：死锁是另一个问题，但数据不一致可能会更严重，具体取决于应用程序领域。假设一个值得交易的领域（银行业，使用规范的例子），死锁的可能性更像是为确保数据一致性而付出的成本，而不是交易使用的问题，或者你会不同意？如果是这样，您会使用哪些其他解决方案来确保无死锁的数据一致性？

Answer 1

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

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

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

Answer 2

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

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

Answer 3

事务的一个问题是数据库中可能（不太可能，但有可能）出现死锁。您必须了解数据库如何工作、锁定、事务等，才能调试这些有趣/令人沮丧的问题。

-亚当

Answer 4

我认为主要问题在于设计层面。我在应用程序中的哪个或哪些级别上使用事务。

例如我可以：

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

在同一应用程序中使用多个这些级别似乎通常会产生性能和/或数据完整性问题。