MySQL共享锁：事务内部的“自锁”机制详解
本文澄清一个关于MySQL共享锁的常见误解。许多开发者认为，一旦获取共享锁，其他事务就不能修改数据，但当前事务却可以修改。 这种现象的根本原因是什么呢？
让我们通过一个例子来理解：
begin; select size from app where id = 1 lock in share mode; -- 获取共享锁 update app set size = size + 1 where id = 1; -- 为什么可以成功？ commit;
这段代码首先使用lock in share mode获取了app表中id=1行的共享锁。根据MySQL共享锁的定义，其他事务只能读取，不能修改该行数据。然而，update语句却成功执行了，修改了数据。这似乎与共享锁的机制相矛盾。
关键在于：共享锁的限制对象是其他事务。 它阻止其他事务修改数据，但不阻止当前事务自身修改。 select ... lock in share mode语句获取的共享锁只对其他事务生效。当前事务已经拥有了对该行的访问权限，因此可以进行修改操作。 可以理解为，当前事务已经“持有”了这个锁，无需再次申请写权限。
因此，update语句能够成功执行的原因是，事务内部的修改不受自身持有的共享锁影响。 这并非共享锁的缺陷，而是其设计机制的一部分，它保证了事务内部的一致性，并允许在事务内混合进行数据读取和修改操作。 所以，理解共享锁的关键在于其作用范围：它限制的是其他事务对已加锁数据的修改。
