二是在更新时，若一次性更新的语句比较多，最好能够选择合适的时候更新。更新某个数据库中记录，其执行所需要的时间往往跟数据库的记录成正比。 其记录越多，更新所需要的时间越多。为此，笔者建议，当需要更新的记录比较多的时候，最好能够选择合理的时机。如有些应用程序在设计时，可以把这个更新放 在后台处理。如此的话，应用程序就可以选择数据库比较空的时候，来更新表中的记录。这无疑可以在很大程度上降低事务对数据库的负面影响。

　　指导方针三：不要在事务处理期间要求用户输入。

　 　数据库管理员在编写事务时，要确保在事务启动之前，让数据库系统获得事务执行所需要的所有内容。如记录的查询条件、所需要更新的内容等等。如果在事务执 行的过程中还需要用户的输入，就回滚当前的事务。当用户提供了必要的参数之后，再重新启动这个事务。因为即使在事务执行的过程中，用户立即响应。但是，用 户的反应速度要比电脑的响应速度慢的多。所以，当用户在事务执行的过程中需要输入参数的话，就会使得这个事务所占用的数据库资源要保持很长的时间。这就有 可能增加阻塞的风险。因为当用户没有及时输入所需要的参数时，事务仍然会保持活动状态，并锁定相关的资源，直到他们响应为止。若用户所需要输入的参数比较 多时，用户可能会几分钟甚至一个小时没有输入。

　　这不是一种理论上的假设，笔者在实际工作中就碰到过这种例子。如在一个ERP系统中有订单变更的功能。若在设计的时候，在用户打开销售订单变更单就触发变更事务的话，则因为用户输入订单变更所需要的时间不能够确定。有时候用户这边改一改，那边再确认一下，可能一个小时就过去了。此时，这张销售订单对应的内容其他用户就无法查看了，因为数据库中已经被这个事务锁住。这显然是设计的不合理的。笔者认为，应到在用户点击确认按钮时，再触发这个变更事务。此时，用户已经输入了所需要更改的所有内容，在更新事务的执行过程中，不需要用户再输入其他的额外参数。通过这种方式，就可以把事务所占用资源的时间缩短到最低。

　　指导方针四：在浏览数据时，尽量不要打开事务。

　　根据笔者的经验，用户更改数据所需要的时间，其实很少。而大部分时间则是在更改数据之前对数据的分析上。如在定位需要对哪些数据要进行更改;如在更改事务递交好的审核;如在考虑该怎么进行更改。这个分析工作所占据的时间往往是大头。

　　故笔者提醒数据库管理员，在所有预备的数据分析完成之前，在用户数据浏览的时候，不要启动事务。也就是说，在用户更改数据的时候，仍然不是触发更新事务的最佳时间。只有到用户确认无误后，选择“更新”按钮，此时，才可以触发这个事务。并且，及时递交或者回滚这个事务。如此，在事后审核的过程中，事务就不会继续占用资源。

　　除了以上这些指导方针外，还有其他的一些小细节要注意。如尽量采用级别低的事务隔离级别，数据库管理员要切记，不是所有的事务都要求串行事务隔离级别;如事务设计的简短一些;如在事务回退时，可根据实际情况选择回退全部事务或者是部分事务等等。另外，要特别注意在事务中排他锁的副作用。在修改数据时，为了保障数据的一致性，往往需要利用排它锁保护修改过的行，以防止其他任何事务读取这一行，并且必须把排它锁控制到递交或者回滚事务为止。为此，数据库管理员在设计跟更新相关的事务时，要合理选择时机。让事务在保障数据安全性的同时，最大限度的降低其负面作用。