update被阻塞时，数据库在等待同一行或表的锁释放；mysql默认50秒超时（innodb_lock_wait_timeout），postgresql需显式设lock_timeout，sql server依赖客户端commandtimeout，不设超时则无限期挂起。
UPDATE 被阻塞时，数据库到底在等什么？
UPDATE 操作卡住不动，通常不是语句本身慢，而是它在等待行锁或表锁释放——比如另一个事务正在修改同一行，且还没提交。此时 UPDATE 会一直挂起，直到锁被释放，或触发数据库级超时（如果配置了）。默认情况下，MySQL 的 innodb_lock_wait_timeout 是 50 秒，PostgreSQL 则默认不设锁等待超时（需手动配置 lock_timeout），SQL Server 依赖客户端设置的 CommandTimeout。不设超时，一个长事务就能让后续所有相关 UPDATE 彻底“冻结”。
MySQL 中用 SET SESSION 控制单条 UPDATE 的等待上限
最直接有效的方式是在执行 UPDATE 前，为当前会话临时调小锁等待超时。这比改全局配置安全，也比靠应用层轮询更可靠：
-
SET SESSION innodb_lock_wait_timeout = 5;—— 把锁等待上限设为 5 秒，超时后报错Lock wait timeout exceeded - 该设置只对当前连接生效，不影响其他会话
- 必须在
START TRANSACTION之后、UPDATE之前设置才有效（事务启动后才开始真正参与锁竞争） - 注意：这个值不能低于 1，也不能高于 1073741824；设为 0 表示立即失败（不等待），但 MySQL 8.0.19+ 才支持
PostgreSQL 必须显式启用 lock_timeout 才能中断阻塞
PostgreSQL 默认完全不检查锁等待时长，UPDATE 会无限期挂起。必须主动开启超时机制：
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
-
SET lock_timeout = '3s';—— 单位支持ms/s/min，超时触发ERROR: canceling statement due to lock timeout - 该设置作用于当前会话，且对所有后续语句生效（包括 SELECT FOR UPDATE、UPDATE、DELETE）
- 它和
statement_timeout独立：后者控制语句执行总耗时，前者只管“等锁”这一阶段 - 若同时设了
lock_timeout和statement_timeout，以先触发者为准
应用层兜底：别只信数据库超时
数据库级超时只能解决“等锁”，但无法覆盖网络中断、客户端崩溃、事务忘记提交等场景。真实系统中必须叠加应用层防护：
- 使用带超时的数据库驱动：如 Python 的
psycopg2.connect(..., options='-c lock_timeout=3s')，或 Go 的context.WithTimeout包裹db.Exec - 避免在事务中混入 HTTP 调用、文件读写等外部 I/O，否则锁持有时间不可控
- UPDATE 前加轻量级预检：例如用
SELECT ... FOR UPDATE SKIP LOCKED（MySQL 8.0+/PG）尝试非阻塞获取锁，失败则快速退避 - 日志里记录每次 UPDATE 的实际执行耗时与是否因超时中止——这是定位长事务源头的关键线索
超时不是越短越好。设成 100ms 可能导致大量误报，设成 300s 又失去保护意义。建议从 3–10 秒起步，在监控中观察 Lock wait timeout 错误率和平均锁等待时间，再动态调整。真正难处理的，永远是那个没 COMMIT 也没 ROLLBACK 的“幽灵事务”。
