SQL数据库锁等待队列不保证公平，饥饿现象常见；根本原因在于队列管理策略、事务行为差异及底层实现，如PostgreSQL的PROC_QUEUE唤醒不确定性、SQL Server的锁升级优先级、InnoDB按trx_id排序唤醒等。
SQL数据库的锁等待队列在并发控制中起关键作用，但其调度机制未必真正“公平”，饥饿现象也并非罕见。核心问题不在锁本身，而在于等待队列的管理策略、事务行为差异以及底层实现细节。
锁等待队列不等于FIFO队列
很多人默认新来的锁请求会排在队尾、先到先得，但实际上多数主流数据库（如 PostgreSQL、SQL Server）的等待队列并不严格按时间顺序服务：
- PostgreSQL 使用轻量级锁（LWLock）和常规锁（LOCK）两套机制，等待队列由共享内存中的
PROC_QUEUE维护，但唤醒逻辑受信号处理、进程状态切换影响，存在微小不确定性； - SQL Server 的锁管理器使用“锁资源哈希桶+等待者链表”，但支持锁升级、超时中断、死锁检测优先级等，导致实际唤醒顺序可能跳过靠前等待者；
- MySQL（InnoDB）采用“锁等待数组 + 按事务ID排序的唤醒尝试”，高优先级事务（如低trx_id或显式设置
innodb_lock_wait_timeout较短）可能被更快响应，而非纯粹排队。
饥饿常由三类行为触发
所谓“饥饿”，是指某个事务长期无法获取所需锁，即使它等待时间最长。常见诱因包括：
- 短事务高频抢占：大量毫秒级事务反复申请并释放同一行锁，使长事务持续处于“刚要上锁就被打断”的状态；
- 锁粒度与升级干扰：例如某事务持有一张表的意向锁（IX），另一事务请求表级排他锁（X），此时所有行级等待者都可能被阻塞，而表级请求若被延迟处理，行级事务就陷入间接饥饿；
- 隐式锁竞争与间隙锁叠加：在可重复读隔离级别下，范围查询产生的间隙锁（Gap Lock）可能覆盖多个待插入位置，新插入事务若总落在已被锁定的间隙内，就会反复重试、循环等待。
可缓解但难根除：实用应对策略
完全消除饥饿不现实，但可通过设计与配置降低发生概率：
- 应用层控制事务粒度：避免在事务中混入网络调用、文件读写等长耗时操作，缩短持有锁的时间窗口；
- 合理选择隔离级别：若业务允许，将RR降为RC可消除间隙锁，大幅减少范围类等待冲突；
- 主动设置锁等待上限：如 PostgreSQL 的
lock_timeout、MySQL 的innodb_lock_wait_timeout，让事务失败快于无限等待； - 监控与识别热点资源：通过
pg_locks、sys.dm_tran_locks或information_schema.INNODB_TRX定期采样，定位长期阻塞源头（如单行更新热点、自增主键争用）。
锁等待的公平性是工程权衡的结果，不是协议保证。理解底层如何调度、哪些行为会放大不均衡，比追求理论上的“绝对公平”更实际。
