在数据库中使用事务有什么问题？
一个明显的问题是可伸缩性/性能。交易使用还会引发哪些其他问题？
您能否说有两套问题，一套用于长期事务，另一套用于短期事务？如果是，您将如何定义它们？
编辑：死锁是另一个问题，但是数据不一致性可能会更糟，具体取决于应用程序域。假设有一个值得交易的领域（例如，银行），那么死锁可能性更像是确保数据一致性所要付出的代价，而不是交易使用上的问题，否则您会不同意？如果是这样，您将使用其他什么解决方案来确保无死锁的数据一致性？
问题来源于stack overflow
写回答
-
它在很大程度上取决于数据库内部的事务实现，也可能取决于您使用的事务隔离级别。我在这里假设“可重复阅读”或更高。将事务长时间保持打开状态（即使是未进行任何修改的事务）会强制数据库保持频繁删除的表的已删除或更新的行（以防万一，您决定读取它们），否则这些事务可能会被丢弃。
此外，回滚事务可能会非常昂贵。我知道在MySQL的InnoDB引擎中，回滚大事务所花的FAR时间比提交它要长（我们已经看到回滚需要30分钟）。
另一个问题与数据库连接状态有关。在分布式容错应用程序中，您永远无法真正知道数据库连接所处的状态。状态数据库连接无法轻松维护，因为它们随时可能失败（应用程序需要记住它所处的状态）。进行并重做）。可以重新连接无状态的状态，并重新发出（原子的）命令而不会（在大多数情况下）破坏状态。
2019-11-18 14:20:56赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
