SELECT FOR UPDATE锁的是扫描路径上的索引记录，非必然锁表或锁行：走索引则锁匹配的索引项（行级+间隙锁），无索引则全表扫描并锁定所有扫描行。
存储过程中用 SELECT ... FOR UPDATE 显式加行锁
在 InnoDB 引擎下，SELECT ... FOR UPDATE 是最直接的行级锁手段，但它只在事务内生效，且必须走索引（否则会升级为表锁）。常见错误是：在存储过程里没开事务就执行该语句，或 WHERE 条件没命中索引，结果锁了全表。
实操建议：
- 确保存储过程以
BEGIN TRANSACTION或隐式事务（如自动提交关掉）开头，否则FOR UPDATE不起作用 - WHERE 子句必须能利用主键或唯一索引，例如
WHERE order_id = ?；若写成WHERE status = 'pending'且无索引，InnoDB 会扫描全表并锁所有匹配行 - 避免在
FOR UPDATE后做耗时操作（如远程调用、大循环），否则锁持有时间过长，加剧竞争
用 INSERT ... ON DUPLICATE KEY UPDATE 实现原子性防重
这是无显式锁、高并发更友好的方案，依赖唯一约束（如业务单号、组合唯一键）。它本质是“尝试插入，冲突则更新”，整个动作由 MySQL 保证原子性，不会因并发导致重复记录。
适用场景：
- 生成幂等订单号、发放优惠券、创建任务调度记录等“首次创建，重复忽略”的逻辑
- 不适用于需严格校验前置状态的场景（比如“只有未支付订单才能改地址”，它无法做条件判断）
- 注意：如果表没有定义对应唯一索引，语句会报错
Duplicate entry ... for key，不是静默失败
存储过程里调用 GET_LOCK() 做应用层互斥（慎用）
GET_LOCK() 是 MySQL 提供的命名锁函数，返回 1/0 表示获取成功/失败。它不绑定表或行，纯内存级，适合跨表、跨业务维度的粗粒度协调（如“同一用户ID不能同时发起两个提现”）。
但容易踩的坑：
- 锁名长度限制为 64 字符，且区分大小写；拼错名等于没锁
- 锁不会随事务自动释放，必须显式调用
RELEASE_LOCK()，否则可能残留死锁 - 超时默认为 31536000 秒（1 年），建议始终传入第二参数，如
GET_LOCK('user_123', 5) - 不支持嵌套调用，同一线程重复获取同一把锁会返回 0（失败），不是重入
为什么不能只靠存储过程封装就解决并发问题
很多人以为“把 SQL 包进存储过程，就天然线程安全”，这是误解。存储过程本身不改变锁行为——DELETE 还是锁行，UPDATE 还是按索引找行，事务边界仍由调用方控制。真正影响并发效果的是三点：
- 事务是否及时提交：一个存储过程里包含 5 条语句，但最后才
COMMIT，那前面所有锁都挂着 - 隔离级别设置：在存储过程开头执行
SET TRANSACTION ISOLATION LEVEL READ COMMITTED可避免REPEATABLE READ下的间隙锁放大 - 调用方式：用
CALL proc_name()直接调用，和从应用层发多条语句，锁生命周期完全一致；区别只在解析开销和网络往返
最关键的细节常被忽略：InnoDB 的行锁是“锁索引项”，不是锁数据行本身。哪怕你 SELECT * FROM t WHERE id = 123 FOR UPDATE，如果 id 不是索引，实际锁的是聚簇索引的整条记录，但代价是全表扫描——这比你想防的“重复”更危险。
