比特网
选择...进行更新在mysql和oracle间锁行为的比较
环境：
[sql]
mysql>显示诸如“%storage_engine%”之类的变量；
---------------- --------
|变量名称 |价值|
---------------- --------
|存储引擎 | InnoDB |
---------------- --------
一组 1 行（0.00 秒）
mysql>选择版本（）；
-----------
|版本() |
-----------
| 5.1.52| |
-----------
组中 1 行（0.06 秒）
[sql]
SQL>从 v$version 选择 *，其中 rownum=1；
横幅
-------------------------------------------- ---------------------------------
Oracle 数据库 10g 企业版版本 10.2.0.1.0 - 64bi
SQL> !uname -a
Linux Think 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
对 mysql 而言，select for update必须在一个事务中，当事务commit时，锁也释放了。，在实验时，一定要加个begin、start transaction或者set autocommit=0。
mysql：
[sql]
------------------sesson_A--------------:
mysql>开始;
查询正常，0 行受影响（0.00 秒）
mysql>; select * from t where i=2 进行更新；
--- ------
|我| n |
--- ------
| 2 | b
|
--- ------
一组 1 行（0.00 秒）
--------- ---------session_B---------------:
mysql>从 t 中选择*；
--- ------
|我| n |
--- ------
| 2 | b
|
| 3 | c
|
--- ------
集合中 2 行（0.00 秒）
mysql>; select * from t where i=2 进行更新；
被阻止...
mysql>;更新 t set n='f' 其中 i=2；
被阻止...
mysql>;更改表 t 删除索引 t_idx；
被阻止...
mysql>;从 t 中删除，其中 i=2；
被阻止...
oracle：
[sql]
---------------- -------session_A--------------
SQL> select * from t where i=1 进行更新；
IN
---------- --------------------
1 大胆思考
------------------------session_B------ ---------
SQL> select * from t where i=1 进行更新；
被阻止...
SQL>更新 t set n='认为开放' 其中 i=1;
被阻止...
SQL>在 t(i) 上创建索引 t_idx；
在 t(i) 上创建索引 t_idx
*
第 1 行出现错误:
ORA-00054: 资源繁忙并在指定 NOWAIT 的情况下获取
SQL>从 t 中删除，其中 i=1；
被阻塞...
于mysql，select ... for update 对记录行加个X锁。其他任何事务想在这些行上加任何锁都会被阻塞。这也符合InnoDB行级锁的概念。
在oracle中，我们再做下一个测试：
[sql]
--------- --session_A-------------
SQL>从 t 中选择 * 进行更新；
A
-----
a
------------- -session_B-------------
SQL>从 v$lock 中选择 sid,type,lmode，其中 sid=159；
SID TY LMODE
------------ -- ----------
159 TM 3
159 TX 6
对oracle，当发出... for update的时候、得到的是RX锁（lmode=3），同时通过trc文件，我们还可以发现，Lck被置为1，也同样被加上了行级锁。
trc部分摘录如下：
[sql]
Itl Xid Uba 标志 Lck Scn/Fsc
0x01 0x000a.029.0000013b 0x008000dd.00c8 .2b C--- 0 scn 0x0000.000911f4
0x02 0x0004.026.00000142 0x008000a3.00c7。 04 --U- 1 fsc 0x0000.00091339
.....
tl: 5 FB: --H-FL-- lb: 0x2 cc: 1
col 0: [ 1] 61
bitsCN.com
