mysql 中这种是什么类型的锁？

你对事务 理解可能有点错误。。。

@a7a2 #1 应该没问题吧，我只是举例 事务 a 里 还有很多其他 sql，只是简单举例说了下

这个还真不是事务，这个只是 MYSQL 的表锁，如果你采用的 MyISAM 引擎，如果是写操作，那么会全表锁，也就是只能等你 a 执行完了，表锁才释放，b 才能继续执行；如果是 InnoDB 引擎，因为是行级锁，就不会有这个问题。

@rodericliu #3 是 InnoDB 引擎。这样的确会锁上，

参考事务隔离级别：
====================================================================================
隔离级别 脏读（ Dirty Read ） 不可重复读（ NonRepeatable Read ） 幻读（ Phantom Read ）
====================================================================================

未提交读（ Read uncommitted ） 可能 可能 可能

已提交读（ Read committed ） 不可能 可能 可能

可重复读（ Repeatable read ） 不可能 不可能 可能

可串行化（ Serializable ） 不可能 不可能 不可能

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

@HypoChen #5 使用的 rr，事务 a 在修改的时候不允许其他事务再去读？像这样的语句 insert into herbal ('medicine') values (1) 关联使用了他，而没去查询他，也算是读？也会锁等待？

herbal 表外键到 medicine，插入时要检查 medicine 存不存在对应的记录，这不是读了吗？一致性要求不高的话用读已提交

@zjp #7 的确是这样，感谢，了解了，我换 rc 吧。

@zjp #7
我测试把 隔离级别改为 RC 了，但是一样会存在这样的问题，

@zjp #7
@HypoChen #5





附了个图，测试了 RR RC 访问级，session2 都会 wait lock。

@letitbesqzr 没说用读已提交能避免锁啊，只是减小冲突率。事务结束时一次性提交的话可重复读和已提交读没区别。

@zjp #11 那像这种情况，只能不去使用外键了？因为就如上 excel 的 session1 和 session2 就算同时在不同事务中执行，也不会造成什么影响吧。

不清楚你的需要…应用层保证数据一致也可以

@zjp 就比如是购物网站，后台正在修改商品 A 的库存数量，但是修改库存数量这个事务在没提交的时候，用户就无法进行购买操作，因为订单数据表里会一个外键字段关联到商品表。

@letitbesqzr 这很正常呀，要是修改库存事务没提交，另外一个用户就购买成功了，不就会出现超卖了吗