传统的事务性锁，读/写会自动加锁，读/写完成后会自动解锁（加解锁机制在细节上复杂），这是一种隐式的锁机制。对于加锁后的并发控制，也就是默认的写不阻塞读，是通过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：咨询锁与普通的隐式锁不会冲突
标签：advisory,事务,sys,unlock,咨询,KingbaseES,隐式 From： https://www.cnblogs.com/kingbase/p/16914744.html