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。这不是事务主动“申请带超时的锁”，而是被动等待 + 被系统强制中断。
如何让锁等待真正“可控”
必须组合三层控制：
- 调低会话级
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 这个安全阀，不是功能开关。
