会卡住，因InnoDB行锁机制导致：若目标行被占，存储过程内SELECT ... FOR UPDATE将等待锁释放或超时（默认50秒），是否卡住取决于索引命中、隔离级别及锁类型，无索引时等效表锁，高并发易阻塞。
存储过程里用 SELECT ... FOR UPDATE 会卡住吗
会，而且卡得非常真实。InnoDB 在存储过程中执行 SELECT ... FOR UPDATE 时，和其他客户端一样，会尝试获取排他锁；如果目标行已被其他事务锁定，当前会话就会进入 waiting for lock 状态，直到锁释放或超时。这不是存储过程的“特殊行为”，而是 InnoDB 行锁机制的自然表现。
关键点在于：存储过程本身不改变锁语义，它只是 SQL 的容器。你写在存储过程里的 FOR UPDATE，和在应用层直接执行效果完全一致——是否等待、等多久、等谁，全由事务隔离级别、索引命中情况、锁类型（记录锁/间隙锁）共同决定。
- 没有索引条件的
FOR UPDATE→ 实际触发全表扫描 + 每行加锁 → 等效于表锁，高并发下极易阻塞 - 用主键或唯一索引查询 → 只锁匹配的单行记录 → 并发安全，等待范围最小
- 用非唯一索引或范围条件（如
WHERE user_name LIKE 'user%'）→ 可能触发间隙锁或临键锁 → 锁住一段范围，增加等待概率
innodb_lock_wait_timeout 在存储过程里怎么生效
这个参数控制的是“单次锁等待最长忍耐时间”，对存储过程内所有需要加锁的操作都起作用，包括 FOR UPDATE、UPDATE、DELETE。默认是 50 秒，超时后整个语句报错：Lock wait timeout exceeded; try restarting transaction。
注意：它不是“整个存储过程”的超时，而是每次锁请求的单独计时。比如你在存储过程中连续执行两次 UPDATE，第一次等了 49 秒拿到锁，第二次又遇到锁竞争，依然会再等最多 50 秒。
- 不能在存储过程中动态修改该参数（
SET innodb_lock_wait_timeout = 10是会报错的，只允许会话级或全局级设置） - 推荐做法是在调用存储过程前，由客户端连接层设置：
SET SESSION innodb_lock_wait_timeout = 15 - 若业务允许部分失败，应捕获
1205（死锁）和1206（锁超时）错误码，做重试或降级
如何避免存储过程因锁等待导致雪崩
核心思路不是“等得更久”，而是“尽量不等”。高并发下靠延长超时时间扛流量，等于把压力从数据库推给应用连接池和用户感知——连接耗尽、响应延迟、前端超时，连锁反应更快。
- 所有
FOR UPDATE必须走主键或唯一索引；用EXPLAIN验证执行计划，确认type是const或eq_ref，绝不能是ALL或index - 减少事务粒度：把长逻辑拆成多个短事务，避免在锁住行的同时还做 HTTP 调用、文件读写等耗时操作
- 用
SELECT ... LOCK IN SHARE MODE替代FOR UPDATE的场景（如仅校验状态不修改），降低锁强度 - 对库存、余额类强一致性场景，优先考虑将判断+更新合并进一条带条件的
UPDATE，例如：UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty >= 1，成功返回影响行数 1 才继续，否则直接失败
为什么在存储过程里加 TRY...CATCH 捕不到锁超时
MySQL 存储过程的异常处理（DECLARE EXIT HANDLER FOR SQLEXCEPTION）能捕获语法错误、数据截断、主键冲突等，但对锁等待超时这类“运行时资源竞争”异常，默认不会触发 SQLEXCEPTION 分支——它抛出的是 SQLWARNING 或直接中断连接，取决于客户端驱动和 MySQL 版本。
更现实的问题是：即使你能捕获，存储过程内部也无法主动“放弃等待”或“降级为乐观锁”。锁等待是引擎层行为，存储过程无权干预。
- 真正可控的只有前置动作：确保索引、缩小事务范围、预检查、用带条件的 DML 替代先查后改
- 锁等待是否发生，不在存储过程代码里，而在你 SELECT 的那条语句是否命中索引、是否被别的事务提前锁住
- 最常被忽略的一点：存储过程调用者（比如 Java 的
JdbcTemplate）可能设置了统一的事务超时，它比innodb_lock_wait_timeout更早掐断请求
