mysql中select ... for update/lock in share mode无sql级超时语法，仅依赖innodb_lock_wait_timeout参数被动中断等待；需配合会话级设值、错误捕获与应用重试实现可控锁等待。

不能靠事务自己“等超时”，得靠 innodb_lock_wait_timeout 参数控制锁等待上限，再配合应用层重试或降级逻辑。

为什么 SET LOCK IN SHARE MODE / FOR UPDATE 不支持 SQL 级超时

MySQL 的 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 本身没有内置的超时语法（比如 WAIT 5 这类）。它会一直阻塞，直到拿到锁、被其他事务释放，或者触发全局的 innodb_lock_wait_timeout 限制后报错 Lock wait timeout exceeded。这不是事务主动“申请带超时的锁”，而是被动等待 + 被系统强制中断。

如何让锁等待真正“可控”

必须组合三层控制：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 调低会话级 innodb_lock_wait_timeout：避免单个请求卡死太久，例如 SET SESSION innodb_lock_wait_timeout = 3;
• 捕获明确错误码：应用中识别 ERROR 1205 (HY000): Deadlock found when trying to get lock 和 ERROR 1205 (HY000): Lock wait timeout exceeded
• 封装重试逻辑：在应用代码里对这类错误做有限次重试（如最多 2 次），每次重连新会话并重置锁等待时间

不要依赖单个长事务内反复尝试——InnoDB 不允许在已持有锁的事务里重新执行 FOR UPDATE 去“刷新”等待；必须回滚后新开事务。

容易被忽略的关键点

即使把 innodb_lock_wait_timeout 设成 1 秒，也不代表每次锁冲突都会在 1 秒后返回：

• 该参数只作用于“等待锁”的阶段，不包含 SQL 解析、执行计划生成、磁盘 I/O 等耗时
• 若事务已持有一部分锁，又去争抢另一行，而对方也卡在类似路径上，可能先触发死锁检测（通常几毫秒内），而非等到超时
• 没有索引的 WHERE 条件会导致全表扫描 → 行锁升级为表锁 → 所有并发更新都被堵住，此时超时只是“症状”，根因是缺失索引

真正的“带超时的锁申请”，本质是应用层用短超时 + 快速失败 + 重试机制模拟出来的，数据库只提供 innodb_lock_wait_timeout 这个安全阀，不是功能开关。