使用SELECT … FOR UPDATE出现意外死锁的问题咨询

1. 能否强制SELECT … FOR UPDATE直接获取排他锁？ #

正常情况下，SELECT ... FOR UPDATE本身就是直接请求**排他锁（EXCLUSIVE锁）**的，但如果事务中已经通过其他操作（比如外键检查）先获取了目标行的共享锁，就会出现“锁升级”的场景。要避免这种情况，核心是调整事务内的操作顺序：把SELECT ... FOR UPDATE放在涉及外键的INSERT操作之前，让事务对目标行的第一次访问就直接申请排他锁，跳过共享锁阶段，自然不会出现锁升级引发的死锁。

另外，部分数据库（如PostgreSQL）支持SELECT ... FOR UPDATE NOWAIT或SELECT ... FOR UPDATE SKIP LOCKED，前者会在无法立即获取锁时抛出错误而非等待，后者会跳过已被锁定的行，但这两种方式仅适合特定业务场景，并非通用的“强制直接拿排他锁”手段——最可靠的方案仍是调整操作顺序。

2. 带外键的INSERT是否会引发共享锁导致死锁？ #

是的，几乎所有支持外键的关系型数据库（比如MySQL InnoDB、PostgreSQL），在执行带有外键的INSERT操作时，都会对外键指向的父表对应行加共享锁（SHARE锁）。这是数据库为保证外键完整性的必要机制：防止插入子行的过程中，父行被删除或修改导致外键失效。

如果两个事务的执行顺序都是：

• 先执行带外键的INSERT，获取父行的共享锁；
• 再执行SELECT ... FOR UPDATE尝试将共享锁升级为排他锁；

就必然触发死锁：每个事务都持有父行的共享锁，都在等待对方释放锁来完成升级，形成循环等待，最终触发数据库的死锁检测机制。

内容的提问来源于stack exchange，提问作者HLP