传统的事务性锁，读/写会自动加锁，读/写完成后会自动解锁(加解锁机制在细节上复杂)，这是一种隐式的锁机制。对于加锁后的并发控制，也就是默认的写不阻塞读，是通过MVCC机制解决的。这种锁完全不需要人为干预。相对于隐式锁机制和MVCC并发控制机制，咨询锁可以认为是一种显式锁，需要人为地控制，这类锁需要显式的申请和释放，在使用这类锁的时候，可以自行控制读写的排他性。
咨询锁
咨询锁有以下类型：
其中：
- sys_advisory_lock/unlock_* 系列是表示获取/释放 session级别的锁，需要通过对应的unlock 解锁，与事务无关，即使事务已经结束，锁也不会释放。
- sys_advisory_xact_* 是用于事务级别的锁获取，没有对应的unlock，事务结束就自动释放
咨询锁使用示例
例子1：即使commit 也不会释放锁
例子2：咨询锁是根据KEY 判断是否冲突。 以下即使是访问不同的表，但key相同，也会冲突。对于咨询锁，在 sys_locks 只是 locktype=‘advisory’ 的一条记录，无其他记录。
例子3：上面可以看到咨询锁冲突的判断只依据key，如果要对不同的表的不同的不同行加咨询锁，可以采用两个参数的版本。即使相同的行，如果KEY不同，不会堵塞；不同的表，key相同，也会堵塞。
例子4：sys_try_advisory_lock 如果获取不到锁，不会等待。try 类型的咨询锁同样分为会话与事务级别，事务级别的锁一般在事务块中使用。
例子5：咨询锁与普通的隐式锁不会冲突
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
