UPDATE依赖问题

[jronald]

UPDATE t1 set a=calc_heavily where id=n
UPDATE t1 set b=a where id=n
有没有可能calc_heavily还没算完，第二个UPDATE就执行了？
如果有问题，要怎么避免？

[撸大湿]

begin tran
UPDATE   t1   set   a=calc_heavily   where   id=n 
UPDATE   t1   set   b=a   where   id=n 
commit tran

UPDATE   t1   set   a=calc_heavily,b=a    where   id=n 

[jronald]

实际中，比这个复杂一点，第二种方法不适用。

第一种不加事务为什么 不行？

[areswang]

事务的原子性
事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性

[dawugui]

UPDATE t1 set a=calc_heavily where id=n
UPDATE t1 set b=a where id=n
有没有可能calc_heavily还没算完，第二个UPDATE就执行了？
如果有问题，要怎么避免？

-------------------

我认为没有可能.不必考虑这个东西.

[hui_hui_2007]

update语句本身就具有原子性吧。

[hui_hui_2007]

update语句本身就是一个隐含的事务

[撸大湿]

to LZ

其实事务的作用只是锁表并在过程出现异常后回滚

在一个存储过程中，语句的先后决定了其执行的先后顺序。所以不必担心

但如果这2条语句是通过多个实例分开运行，那他的执行次序就有可能颠倒，特别是多核服务器。

[jronald]

明白了，我再调试一下
多谢各位