1. SELECT FOR UPDATE 核心机制解析

第一次接触 SELECT FOR UPDATE 是在处理电商秒杀系统时遇到的库存超卖问题。当时发现明明在代码里做了库存检查，但在高并发场景下还是会出现负库存。后来通过排查发现，问题就出在没有正确理解和使用行锁机制。

排他锁（X锁）是 SELECT FOR UPDATE 的核心武器。它就像你在超市货架上拿起商品查看时，顺手贴了个"已预订"的标签。其他顾客可以看到这个商品，但想要拿取就必须等你放下（事务提交）或者取消预订（事务回滚）。在 MySQL 的 InnoDB 引擎中，这种锁的触发条件非常讲究：

-- 典型的使用示例 BEGIN; SELECT stock FROM products WHERE id=1001 FOR UPDATE; UPDATE products SET stock=stock-1 WHERE id=1001; COMMIT;

这里有个容易踩坑的地方：很多人以为 FOR UPDATE 只是简单的行锁，实际上它的锁行为会根据查询条件和索引情况发生戏剧性变化。我曾经在测试环境模拟过，当使用无索引字段查询时，整个商品表都会被锁住，导致其他正常库存操作也被阻塞。

2. 主键条件下的精准锁定

主键查询是 FOR UPDATE 最理想的使用场景。去年优化过一个会员积分系统，当时在用户积分变更操作中使用了主键锁定：

SELECT * FROM user_points WHERE user_id=123 FOR UPDATE;

主键锁定的特点就像精准的外科手术：

• 只锁定 WHERE 条件匹配的特定行
• 其他事务可以正常读写其他行数据
• 锁等待超时会抛出 Lock wait timeout 异常

实测发现一个有趣现象：即使查询条件包含多个主键值，MySQL 也会很智能地只锁定目标行。比如WHERE id IN (1,2,3)就只会锁定这三行，不会升级为表锁。这种特性在批量操作时特别有用。

3. 唯一索引的锁行为差异

唯一索引的锁定行为与主键非常相似，但有个关键区别需要注意。在开发支付系统时，我们遇到过这样的情况：

-- order_no 是唯一索引 SELECT * FROM payments WHERE order_no='PAY20230801001' FOR UPDATE;

唯一索引的特殊之处在于：

1. 锁定的实际上是索引项而非物理行
2. 即使该行不存在也会产生间隙锁（Gap Lock）
3. 在 RR（可重复读）隔离级别下表现更严格

有次我们排查线上问题，发现两个看似不相关的支付订单互相阻塞。后来发现是因为这两个事务都在等待同一个不存在的订单号（order_no）的间隙锁，这种隐式锁定需要特别注意。

4. 普通索引的锁范围陷阱

普通索引的锁定范围往往比开发者预期的要大。在商品分类系统优化时，我们曾用分类ID（普通索引）做锁定：

-- category_id 是普通索引 SELECT * FROM products WHERE category_id=5 FOR UPDATE;

这种情况下会触发索引范围锁：

• 锁定所有 category_id=5 的记录
• 同时锁定 category_id=5 前后的间隙
• 其他事务无法插入 category_id=5 的新记录

这种锁定在商品批量上下架时很有用，但要注意它会阻塞同类目商品的新增操作。我们后来通过细化锁粒度（改为批量单行锁定）解决了这个问题。

5. 无索引查询的表锁风险

最危险的情况莫过于在无索引字段上使用 FOR UPDATE。在早期的一个日志处理系统中，我们曾这样写：

-- status 字段没有索引 SELECT * FROM task_queue WHERE status='pending' FOR UPDATE;

这会导致全表锁定：

1. 不仅锁定所有符合条件的行
2. 还会阻塞所有其他事务的写操作
3. 甚至可能阻塞部分读操作

有次因为这个锁表问题，导致整个后台管理系统卡死。解决方法要么加索引，要么改用更精确的查询条件。

6. 间隙锁与幻读防护

在 MySQL 默认的 RR 隔离级别下，FOR UPDATE 还会产生间隙锁（Gap Lock）。这在我们做订单编号生成器时特别重要：

-- 假设 order_id 是普通索引 SELECT MAX(order_id) FROM orders FOR UPDATE;

间隙锁的特性包括：

• 锁定索引记录之间的间隙
• 防止其他事务在范围内插入新记录
• 有效解决幻读问题

但这也带来一个副作用：当批量插入连续订单时，会产生严重的锁竞争。我们最终采用 UUID 替代自增ID来缓解这个问题。

7. 实战锁优化策略

经过多次踩坑，我们总结出几个实用优化方案：

锁降级策略：

-- 先尝试快速获取锁 SELECT * FROM table WHERE id=1 FOR UPDATE NOWAIT; -- 如果失败再等待 SELECT * FROM table WHERE id=1 FOR UPDATE SKIP LOCKED;

锁超时控制：

-- 设置锁等待超时（单位：秒） SET innodb_lock_wait_timeout=3;

复合索引优化： 对于WHERE a=1 AND b=2这样的查询，建立 (a,b) 复合索引比单列索引更能精确控制锁范围。

在最近的一次大促中，通过这些优化，我们的库存服务成功支撑了每秒 5000+ 的并发扣减，没有出现任何超卖或死锁情况。关键是要根据业务特点选择合适的索引策略，并充分测试不同并发场景下的锁行为。