解析Oracle数据库编写有效事务指导方针_Mssql数据库教程

　　在事务中，若执行Update等记录操作语句，数据库为了保障数据的一致性，会对其所访问的记录加锁，防止在同一时间内其他用户对其修改。此时，若其他用户需要访问加锁的记录，则必须等待。此时就会发生锁冲突。

　　所以，在事务中要尽量使得访问的记录量最小。如此就可以减少锁定的行数，从而减少事务之间的冲突。这要求数据库管理员在事务中尽量精确的定位语纪录。如在数据库中读取记录时，最好能够使用Where语句进行定位。并且在编写Where语句的时候，要尽量的详细，最好能够实现一对一，则是最好的。

　　如在库存盘点的时候，事务处理语句需要从数据库中读取一定数量的记录，并且为这些记录进行加锁。此时，若记录读取的过多的话，就会对其他用户访问表中的记录造成麻烦。为此，数据库管理员应该建议应用前台应用程序在开发的过程中，加入一些限制条件。如按照产品的分类来更新库存。如此的话，就可以减少一个事务一次性读取的记录数量，从而把锁的影响降低到最低。

　　指导方针二：保持事务尽可能的简洁。

　　在事务中尽量使得访问的纪录最小，这是从数量的角度来考虑锁冲突。而保持事务尽可能的简洁，则是从时间的角度来考虑避免锁冲突的事情。保持事务尽可能的简洁，主要是要求数据库管理员在编写事务的时候，不要把事务写的太过于庞大与复杂。否则，事务在执行的时候就会占用比较多的时间。而这直接导致的后果就是数据库会把某些记录、甚至一张数据表锁住比较长的时间。这就会恶化锁对数据库的负面影响。

　　故当用户在知道了必须要进行修改的记录之后，就要马上启动事务;并且在最短时间内执行完相关的修改语句，然后立即递交或者回滚。而且，只有在确实需要时，才打开事务语句。具体的来说，数据库管理员在事务的简洁性方面，可以尝试如下方法。

　　一是在同一个事务中不要加入过多的修改或者删除语句。如当用户需要更新用户信息表中的相关数据。例如在员工的编号前加入YG前缀并且同时根据员工入职年份计算员工工龄。这两个更新语句若从技术上来说，放在同一个事务中并没有什么不妥。但是，当员工数量比较多时，若把他们合并在一起，则这个事务执行得时间会比较久。为此，最好在更新数据库表的时候，若预计执行时间会比较长，则最好能够把更新语句进行分割，如一列列更新等等。

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

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

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

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

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

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

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

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