sql - SQL 事务的实际成本是多少？

Question

这需要一些背景知识。我正在创建一个 Web 应用程序(带有 SQL Server 后端的 ASP.NET/VB.NET)，它将接受申请以接收资金，并且此表单包含三个人的联系信息字段。因为所有三个人的信息(姓名、电子邮件、电话)都相同，所以我选择将联系信息存储在与应用程序分开的表中。在应用程序表中，这三个联系人中的每一个都有一个 ID 字段，指向联系人表中的一个联系人。

但是，这在我的 CRUD 工作中提出了一个有趣的问题/问题。我能想到的在一个 SQL 事务中为应用程序和所有三个联系人创建、更新和检索信息的唯一方法需要非常复杂的存储过程。换句话说，通过多个事务检索此信息会更简单(对我而言)。然而，由于这些信息从来都不是独立需要的，所以我总是会进行多次交易来获取一个应用程序的信息。

所以我的问题:

1. 这种设计是不是有点矫枉过正？每个应用程序的联系人不会超过三个，并且必须恰好三个。将此信息删除到单独的表格中是否过于复杂？
2. 与编写复杂的存储过程并且只需要一个事务相比，执行多个 SQL 事务的实际成本是多少？
3. 一般来说，使用 ADO.NET 对 Web 应用程序执行 SQL 事务的成本是多少？

感谢您接受冗长的解释。

*编辑*

在阅读了您的一些回复后，看来我使用“交易”一词是错误的。我实际上好奇的是跨单个连接执行多个查询而不是执行一个查询的成本。很抱歉造成误会。

Answer 1

需要事务将数据库从一种一致状态移动到另一种一致状态。这里的“一致”适用于数据库的应用程序 View 。典型的例子是两个账户之间的转账:你必须从一个账户借记，另一个账户贷记。在这两个操作之间，数据库是不一致的，有一些钱已经“消失”(从一个帐户中扣除的金额无处)。但在事务结束时，数据库再次保持一致。您需要一个事务来跨越这两个操作，以防止读者查看不一致的数据库，并在发生崩溃时确保数据库一致。

您说要在单个事务中处理逻辑中的多个项目，您需要复杂的程序。这不是真的，事务范围与请求范围正交:客户端可以启动事务，通过在 3 个调用中调用 3 个过程来执行 3 个操作，然后提交事务。 不要求所有操作都在一个存储过程中完成。

所以事务应该不导致显着的程序开销。事实上，程序会忽略事务。一个编写良好的过程在事务内部调用以及在没有事务的情况下调用时都应该正确运行。见 Exception handling and nested transactions用于在存在事务和异常时正确运行的过程模板。

最后，交易的真实成本是多少？事务写入 数据(读取并不真正需要事务)，因此它们锁定 修改的行。当试图读取这些被阻塞的行时，读取通常会阻塞，然后事务越长，它锁定行的时间越长，它阻塞的读取就越多。但是有一个非常简单的解决方案:快照读取。快照读取确实是一种神奇的 Sprite 尘埃，它们允许应用程序不受阻塞行的阻碍，因为读取器始终可以读取阻塞更新之前的行版本行。见 Using Row Versioning-based Isolation Levels .

所以结论很简单:交易没有成本。仅仅是因为除了交易之外别无选择。不是“X 比 Y 慢”的问题，而是“X 是唯一正确的替代方案”的问题。

更新

编辑后:多个请求与一个请求的成本哦可能很大。到服务器的往返(即在打开的连接上发出请求)具有固定成本。如果您进行多次往返，那么您为每个请求支付此固定成本。如果您使用多个过程调用执行一个请求，则此固定成本只需支付一次。在非常热的系统上，这种差异是可以测量的，并且会影响整体性能。但我说的是真正很热的系统，每秒有数千个请求。解决方案通常不是使过程复杂化，而是在一个请求中发出多个过程调用:

SqlCommand cmd = new SqlCommand(@"
exec usp_firstProc @arg1, @arg2;
exec usp_secondProc @arg2, @arg3;
exec usp_thirdProc @arg1, @arg3;", connection);
cmd.Parameters.Add("@arg1", someValue);
...
cmd.ExecuteNonQuery();

但我必须说，除非您有一个 非常热 的工作负载，否则这个解决方案并不是真正需要的。作为一个粗略的规则，对于任何低于 1000 个请求/秒的东西，我会认为清晰代码的好处大于性能好处。

如果您必须为每个请求打开一个新连接，则有一点不同。登录握手真的很昂贵，可以用数百毫秒来衡量。但解决方案很简单:使用连接池(在 ADO.Net 中默认启用)并且不要过早丢弃应用程序中的连接，保持连接并重用它，直到整个工作单元完成。