关于行锁的几个问题.

[小小小小周]

create table test_innodb_lock (a int(11),b varchar(16)) engine=innodb;
create index test_innodb_a_ind on test_innodb_lock(a);
create index test_innodb_lock_b_ind on test_innodb_lock(b);

session 1:

set autocommit =0;
update test_innodb_lock set b=22 
where b=6;

session 2:

update test_innodb_lock set b=33 
where b=5

疑问:
这里为什么被锁住,他们更新的不是同一行.

==============================================================

[ACMAIN_CHM]

加上B为主键试试。

[小小小小周]

还是一样的情况,不知道行锁是怎么样才算行锁的..

[小小小小周]

请问狼头大哥:
update test_innodb_lock set b=22
where b=6;
上面的语句有使用到索引吗?

[zuoxingyu]

你表里的记录太少了，计划任务觉得不用索引还快，就决定全表扫描，然后就全表锁定了。

你多做写测试数据看看。

[小小小小周]

要是数据够多的话,上面的这个语句 会不会使用索引呢

[小小小小周]

zuoxingyu 正确,非常感谢.

[小小小小周]

带另一个问题:
session1:

set autocommit=0;
update test_innodb_lock
set b = 'bbbbb' where a = 1 and b = 2

session2:

update test_innodb_lock
set b = 'bbbbb' where a = 1 and b = 1100

这个是足够数据的条件下为何也会锁住?

[zuoxingyu]

MYSQL使用的一种间隙锁，就是说两条记录之间的记录，虽然没有被访问，但是也被锁住了，好像是为了避免幻读而做的。

你另外一个问题我觉得可能是间隙锁锁住了。

[曾经的阿飞]

你要讨论这个问题，贴出你的show global variables like 'tx_isolation';
在不同的隔离级别下锁是不一样的，默认是repeatable read，在这种情况下假如不执行select for update是不会产生间隙锁的。

第二个问题是因为innodb的锁机制是基于索引的，你把第二个例子把a、b的索引都删掉，然后增加一个a和b的联合索引，你再试验一下，看还锁不

[曾经的阿飞]

你把第二个例子把a、b的索引都删掉，然后增加一个a和b的联合索引，你再试验一下，看还锁不
哥，你试验了没

[小小小小周]

实验了,还是锁的.我认为就是使用同一个索引,不同数据也会导致锁定