mysql中的get_lock锁机制解析

1|0mysql中的get_lock锁机制解析

GET_LOCK(key,timeout) 需要两个连接会话
RELEASE_LOCK(key) 锁是否释放，释放了返回1
IS_FREE_LOCK(key) 返回当前连接ID，表示名称为'xxxx'的锁正在被使用。
   key 锁的名字，timeout加锁等待时间，时间内未加锁成功则事件回滚。get_lock 加锁成功返回1，
   这个锁是应用程序级别的，在不同的mysql会话之间使用，是名字锁，不是锁具体某个表名或字段，具体是锁什么完全交给应用程序。它是一种独占锁，意味着哪个会话持有这个锁，其他会话尝试拿这个锁的时候都会失败。
   session A select get_lock('test',1);
   session B select get_lock('test',5);
   可以指定表也可以不指定
   直到关闭连接会话结束，锁才会释放，但不像redis那样加了锁只要不主动释放就一直有。
   但是当会话1 get_lock 后，未释放。会话2 不get_lock 同一个key，或者就不get_lock,依然可以对数据进行任何操作，所以加锁只是说人为的主观的想要让某些操作同时只有一个连接能进行操作，别的连接不调用get_lock加同一个锁，那它不会受到任何影响，想干什么干什么。

session1

session2

get_lock：但是当会话1 get_lock 后，未释放。会话2 不get_lock 同一个key，或者就不get_lock,依然可以对数据进行任何操作，所以加锁只是说人为的主观的想要让某些操作同时只有一个连接能进行操作，别的连接不调用get_lock加同一个锁，那它不会受到任何影响，想干什么干什么。

session1

session2

优缺点分析（1）这种方式对于更新所有列比较有效，但是得把查询的语句也放在锁内执行；（2）这种方式当客户端无故断线了会自动释放锁，比较好，不像redis锁那样，如果加完锁断了，那么锁一直在；（3）这种方式是针对锁内的所有操作加锁，并不针对特定表或特定行，所以使用了同一个Key的锁但不同的操作都会共用一把锁，会导致效率低下；（4）如果查询语句放在锁之前，则数据可能是旧的，更新之后会把查询之后更新之前别的客户端更新的数据覆盖掉；

__EOF__

本文作者：komomon
本文链接：https://www.cnblogs.com/forforever/p/13019527.html
关于博主：喜欢读书、旅行、爬山。评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！