SQL Server事务详解

SQL Server中的事务机制，可以说是保证数据一致性的核心工具。很多初学者刚接触时，总觉得它有点抽象，甚至觉得“不就是一组操作嘛”。但真正遇到数据对不上的时候，才会明白事务有多关键。下面我们就通过一个典型的转账场景，把这个概念彻底拆开揉碎了讲清楚。

先搭一个存款表，准备两位用户

先把场景搭好。创建一个简单的存款表，里面放两条用户记录，每个用户有ID、姓名和余额。表结构不必复杂，够用就行。

接着查询一下这张表，看看数据是不是完整。

现在场景来了：李冬冬要向黄少明借一千元。这个操作在数据库里怎么实现？其实就是两步：扣掉李冬冬账户1000，加到黄少明账户上。很简单的两条UPDATE语句，对吧？

具体来说：先把表_存款中id为1的余额减去1000，再把id为2的余额增加1000。执行完再查一下表，结果看起来挺正常。

但问题来了——假如李冬冬再次借款，这次是五千元。如果余额不够扣，会发生什么？

余额字段如果没加约束，就会出现负数。这显然不合逻辑。所以得给余额列加上一个CHECK约束：余额必须大于等于零。进入设计表界面，添加约束，保存后即刻生效。

恢复原始数据后重新执行转账，来看看结果。

再试一次转账五百元——这时候数据库会给出错误消息547，提示UPDATE语句违反了CHECK约束，操作被终止。但注意，第一个扣款语句（减少5000）失败了，而第二条加款语句（增加5000）却成功执行了。这就造成了数据不一致：钱扣了但没加到对方账户？不对，实际上是扣款失败、加款成功，等于凭空多了钱。

这种情况在现实中意味着什么？如果银&行系统出现类似问题，后果不堪设想。因此必须引入事务概念。

事务：要么全成功，要么全失败

事务的核心思想非常简单：把一组操作打包，要么全部成功，要么全部失败，绝不允许部分成功部分失败。比如刚才的转账，扣款和加款必须作为一个整体——如果扣款成功了但加款失败（或者反过来），整个操作就应该撤销，回到最开始的状态。

这就好比一手交钱一手交货，任何一方没完成，交易就不算数。

在SQL Server中，默认情况下每条SQL语句是一个独立事务。但我们可以手动控制事务的开始、提交和回滚。事务有三个关键词：BEGIN TRANSACTION（开始事务）、COMMIT（提交事务）、ROLLBACK（回滚事务）。可以把它想象成游戏里的存档点——开始事务就是存档，如果后续操作顺利就提交（保存存档），如果出了岔子就回滚（读档重来）。

来看具体操作：先开启事务，然后对id1账户加10000元试试。

再查一次，发现id1余额确实增加了，但注意——这笔变更还没有最终生效，它只存在于当前会话的临时空间里。必须执行回滚或提交才算结束。

如果执行ROLLBACK，数据就会恢复到事务开始前的状态。如果执行COMMIT，则变更持久化到数据库，其他用户也能查到了。

完整转账事务的SQL实现

下面用一段完整的SQL代码来演示事务在转账中的应用。我们用了一个变量来记录受影响的行数，如果两条UPDATE语句都成功（影响行数为2），就提交事务；否则回滚。

先声明一个整型变量@影响行，初始值为0。然后开始事务，执行扣款语句，把受影响行数累加到变量上；再执行加款语句，同样累加。最后判断变量是否等于2——是则提交，否则回滚。

如果转账两千元，执行后查表，数据正确，事务成功提交。

关于事务，还有一个重要概念需要提一下：锁。事务在执行过程中会涉及共享读锁和独占锁（增删改操作）。共享锁允许多个事务同时读取，而独占锁则会阻塞其他事务的写入或读取。这些细节在网上有很多资料，如果想深入理解，可以查阅MSDN中关于事务隔离级别的说明。

总而言之，事务是数据库操作中保证数据完整性和一致性的基石。从简单的转账场景就能看出，没有事务的约束，数据随时可能陷入混乱。用好事务，才能让我们的数据操作真正可靠。