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语句能够成功执行的原因是，事务内部的修改不受自身持有的共享锁影响。 这并非共享锁的缺陷，而是其设计机制的一部分，它保证了事务内部的一致性，并允许在事务内混合进行数据读取和修改操作。 所以，理解共享锁的关键在于其作用范围：它限制的是其他事务对已加锁数据的修改。
以上就是MySQL共享锁的误区：为什么事务内部可以修改已加共享锁的数据？的详细内容，更多请关注【创想鸟】其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：PHP中文网，转转请注明出处：https://www.chuangxiangniao.com/p/2539366.html
