sql-server - 每个多个数据库连接都有一个事务什么时候有意义？

Question

谁能帮我看看在什么样的场景下拥有一个共享数据库事务和多个连接是有意义的？谢谢。

Answer 1

如果您的意思是多个数据库都在一个事务中更新，那么您可以为 Atomicity 执行此操作 - http://en.wikipedia.org/wiki/Atomicity_(database_systems)

假设考虑银行转账，每个账户提供商都有不同的数据库 - 钱必须离开一个账户并更新到另一个账户。如果它在中途失败——例如第二次数据库更新失败，那么钱已经离开了一个账户但没有到达另一个账户，这是不可接受的。

事务意味着其中一个更新失败意味着它们都被取消（回滚），以使数据保持事务开始之前的状态。

Answer 2

就我个人而言，我认为它在 RDBMS 中并不明智——但是我可以看到它降低了非常高负载数据库的设计复杂性。

例如，在电子商务案例中，您可能会将它们分区，以便产品库存在一个数据库上，而订单在另一个数据库上。在这种情况下，您不会在处理订单时减少库存计数并增加发票计数——在这种情况下，全局事务将是有意义的。

但是 99% 有更好的替代方案可以在设计中解决。

-- 编辑：全球事务的陷阱 --

这两点是我建议不要使用全局事务的原因

第 1 点：

全局事务涉及多个数据库服务器（或者至少它们应该）——一个全局事务需要一个 DTC（分布式事务协调器）——使用这样的代理会降低你的查询速度，因为事情不是这样的在单台机器的范围内完成，但涉及多台机器，这意味着网络。

第 2 点：

如果您的查询设计不正确（大多数人不了解其中的细微之处），您最终可能会锁定单个数据库上的大部分表，有时人们甚至最终会使用单个查询锁定整个表。如果没有针对分布式查询进行适当的设计，您的应用程序将停滞不前，并且有人会被解雇：D。您需要确保您的查询最终只锁定它们必须锁定的内容，并且您必须尝试确保数据的这些锁定部分仅由一个查询同时使用。

为什么在分布式查询中锁定表更糟糕？因为第 1 点。您现在锁定最后一个订单的订单时间更长。

-- 编辑：您可能想要调查的潜在领域 --

集群技术和 HPC 经常使用分布式锁管理器。通过研究这些技术的数据管理变体，您将学到很多东西，因为它们会向您展示这些实现认为有必要在哪些地方获得全局锁（这是全局事务所做的）。

Answer 3

当您想要影响多个数据库的事务操作时。