急高手指点：一个事物的长度有无限制，如果太长，恢复或者回滚的时候有无影响，能保证正常吗？

Question

没有什么限制，事务甚至可以跨批处理。当然这样性能就大受影响了。
在提交事务时，脏页必须写入日志文件(但不一定要立即写入mdf)并确认才算提交成功。否则提交失败。checkpoint指这样的时刻（shut server,或一定时间间隔后）：部分脏页被写入日志文件或数据文件。大体如此，具体可参见bol的"检查点和日志的活动部分"条。

Answer 1

（本地而非分布式的）事务是这样操作：1. 开始一个事务。
2. 修改（包括新增和删除）任何数据时，将原记录（或者更大范围，比如页面、表等等）加锁，然后保存要修改的结果。重复这个过程。
3. 事务提交命令则开始提交事务过程，即将保存的更改结果真正写入数据原来的位置。
4. 事务回滚命令则比较简单，将保存的数据修改计划丢弃就是了。因此此过程与事务中更新的数据的多少无关。如果在事务未提交也未回滚的过程中，服务器崩溃了，那么服务器重新启动时自动回滚此事务。如果此事务在回滚过程中服务器崩溃了，服务器启动时仍然回滚。如果此事务在提交过程中服务器崩溃了，服务器启动时可以根据保存的数据更新计划再次进行提交，这样即使服务器经常宕机数据也会尽量完好地提交到数据库。这最后一点才是事务处理的“真谛”。SQL Server某些版本为了有一个好的“性能”，而牺牲了可靠性。他将数据更新资料保存在内存中而不是硬盘上。数据库遇到意外故障时很容易丢失最后的事务中的数据。

Answer 2

我发现大多数包括很多自称数据库程序员的人，都认为事务的性能就决定于需要保存的更新计划的数量。显然这是错误的。当数据记录被锁时，所有访问磁记录的用户进程都要排队等待。而用户的查询更新动作通常要访问很多分布在数据库中不同部分的数据，因此数据库中记录锁发生碰撞的情况非常常见，因此在此及时改进一点性能也是非常有意义的。但是关键是：不仅仅需要修改的数据，即使需要读取的数据也会被锁住，从而使用户进程停顿。比如，一个用户的应付款余额为1万元，现在有一个结算程序将这个余额要增加5千，同时另一个结算程序要将余额增加8千，那么结果这个用户的余额是1万5千呢？还是1万8千呢？当然应该是2万3千。真正正确的事务，在其中凡是读取过的记录都要加锁（其他用户不能读取），并不是仅仅要修改的数据才上锁。所以对事务处理要非常谨慎，尽可能用编程的努力换得程序在高峰期的事务处理的平稳性。多年以前我写过一个小程序，20个终端联调测试时性能完全可以。结果一使用就赶上了年度使用高峰，本来5分钟可以作完的工作这下子几个小时也做不完了。至于那些认为有事务和没事务都没有大差别的人，我想应该改行不要再做程序员或者DBA了，否则用户丢了的钱谁赔？