3.2w+
社区成员
- 主页
- 基础类
- 应用实例
- 新技术前沿
UPDATE依赖问题
UPDATE t1 set a=calc_heavily where id=n
UPDATE t1 set b=a where id=n
有没有可能calc_heavily还没算完，第二个UPDATE就执行了？
如果有问题，要怎么避免？
UPDATE t1 set b=a where id=n
有没有可能calc_heavily还没算完，第二个UPDATE就执行了？
如果有问题，要怎么避免？
...全文
请发表友善的回复…
发表回复
jronald 2007-12-19
明白了，我再调试一下
多谢各位
多谢各位
撸大湿 2007-12-19
to LZ
其实事务的作用只是锁表并在过程出现异常后回滚
在一个存储过程中，语句的先后决定了其执行的先后顺序。所以不必担心
但如果这2条语句是通过多个实例分开运行，那他的执行次序就有可能颠倒，特别是多核服务器。
其实事务的作用只是锁表并在过程出现异常后回滚
在一个存储过程中，语句的先后决定了其执行的先后顺序。所以不必担心
但如果这2条语句是通过多个实例分开运行，那他的执行次序就有可能颠倒，特别是多核服务器。
hui_hui_2007 2007-12-19
update语句本身就是一个隐含的事务
hui_hui_2007 2007-12-19
update语句本身就具有原子性吧。
dawugui 2007-12-19
UPDATE t1 set a=calc_heavily where id=n
UPDATE t1 set b=a where id=n
有没有可能calc_heavily还没算完，第二个UPDATE就执行了？
如果有问题，要怎么避免？
-------------------
我认为没有可能.不必考虑这个东西.
UPDATE t1 set b=a where id=n
有没有可能calc_heavily还没算完，第二个UPDATE就执行了？
如果有问题，要怎么避免？
-------------------
我认为没有可能.不必考虑这个东西.
areswang 2007-12-19
事务的原子性
事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性
事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性
jronald 2007-12-19
实际中，比这个复杂一点，第二种方法不适用。
第一种不加事务为什么 不行？
第一种不加事务为什么 不行？
撸大湿 2007-12-19
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