select ... for update 未锁住的根本原因是事务未正确包裹或隔离级别不足；必须在begin/commit内执行，避免隐式提交、确保索引使用，并注意数据库版本差异。
存储过程里用 SELECT ... FOR UPDATE 为什么没锁住？
常见现象是：两个并发请求同时执行同一个存储过程，SELECT ... FOR UPDATE 返回了相同记录，后续 UPDATE 还是发生了覆盖写入。根本原因不是语句写错了，而是事务隔离级别太低，或者没在事务里执行。
- MySQL 默认隔离级别是
REPEATABLE READ，但SELECT ... FOR UPDATE只在当前事务内生效，必须确保整个逻辑包裹在BEGIN/COMMIT中 - 如果存储过程里有
COMMIT或隐式提交（比如 DDL 操作），锁会提前释放，后续语句就不再受保护 - 注意索引：没走索引的
SELECT ... FOR UPDATE会升级为表锁，性能崩，还可能引发死锁 - PostgreSQL 不支持
FOR UPDATE在函数外生效，必须显式BEGIN，且不能跨事务调用
乐观锁在存储过程中怎么加才不白加？
很多人加个 version 字段、在 WHERE 里判断，但发现并发时还是更新成功了——问题出在“检查”和“更新”没原子化。
- 必须把
SELECT version和UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?放在同一 SQL 里完成，不能拆成两步（尤其不能先查再拼 SQL） - MySQL 存储过程中可以用
ROW_COUNT()判断是否真的更新了行：IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Optimistic lock failed'; END IF; - 乐观锁适合读多写少、冲突概率低的场景；高频更新下失败重试成本高，反而不如悲观锁干脆
- 注意时钟一致性：不要用
NOW()或UNIX_TIMESTAMP()做版本号，不同节点时间差会导致误判
存储过程里混合用悲观锁和乐观锁反而更危险
比如先 SELECT ... FOR UPDATE 查库存，再用 version 字段做二次校验——这不仅多余，还会延长锁持有时间，放大死锁风险。
- 悲观锁和乐观锁解决的是不同问题：前者防并发修改，后者防覆盖写入；混用等于把两种机制的缺点都继承了
- 如果业务逻辑本身需要强一致性（如扣减余额），就老实用悲观锁，别画蛇添足加乐观校验
- 如果已用乐观锁，就别在同个事务里再
FOR UPDATE，否则锁范围扩大，可能阻塞无关操作 - 特别注意存储过程里的临时表或游标：它们可能隐式触发额外锁，导致本不该被锁的行也被卡住
GET_LOCK() 在 MySQL 存储过程中能当分布式锁用吗？
不能。它只在单实例内有效，且不和事务绑定，崩溃后锁不会自动释放，也不支持超时自动清理。
-
GET_LOCK('order_123', 10)返回 1 表示拿到锁，但这个锁和当前连接绑定，连接断开就释放，没法保证业务逻辑执行完才释放 - 不支持可重入，同一连接重复调用会覆盖前一次锁状态
- 没有锁等待队列，所有等待者是“抢”的，容易造成惊群效应，日志里一堆
GET_LOCK失败但业务没感知 - 真正需要跨会话协调时，应该用外部方案（如 Redis 的
SET key value EX 30 NX），而不是硬塞进存储过程
FOR UPDATE SKIP LOCKED 的支持更稳，但老版本可能直接报错；而 PostgreSQL 的 SELECT ... FOR NO KEY UPDATE 在更新非主键字段时更轻量——这些细节不验证，光看文档就写，八成踩坑。
