Yii框架悲观锁实现全解析

本文深入剖析了在 Yii 框架中实现 MySQL 行级悲观锁的关键原理与实战要点：由于 Yii 并未封装 RESTful 接口级的悲观锁抽象，开发者必须摒弃对 ActiveRecord 自动加锁的误解，转而手动开启 InnoDB 事务、通过 createCommand() 显式执行 SELECT ... FOR UPDATE，并确保后续业务操作（如库存扣减）严格在同一事务内完成；文章以订单扣库存为例，清晰展示了从事务启动、加锁查询、业务校验到原子更新的完整闭环，同时强调了锁生命周期不可跨请求、高并发下的等待风险及业务层需自主决策加锁时机与降级策略等易被忽视的核心挑战——真正考验开发者的，不是那行 SQL，而是对数据一致性边界的深刻理解与工程权衡能力。

Yii 框架本身不提供 RESTful 接口级的“悲观锁”抽象，SELECT ... FOR UPDATE 必须手动在事务中显式调用，且仅在 InnoDB + 手动事务控制下生效。直接依赖 ActiveRecord 的 save() 或 updateAll() 不会自动加行锁。

RESTful 接口中怎么触发 MySQL 行级悲观锁

悲观锁不是 Yii 的功能开关，而是你主动发起的数据库语句行为。关键点在于：必须开启事务、使用原生 SQL 或 createCommand() 执行 SELECT ... FOR UPDATE，且不能依赖 AR 查询结果直接修改后 save() —— 那样会丢失锁上下文。

• 必须用 Yii::$app->db->beginTransaction() 显式开启事务（InnoDB 默认 autocommit=1，不开启事务时 FOR UPDATE 无效）
• 锁必须由 createCommand() 发起，例如：Yii::$app->db->createCommand("SELECT * FROM user WHERE id = :id FOR UPDATE")->bindValue(':id', $id)->queryOne()
• 后续的 UPDATE 或业务逻辑必须在同一事务内完成，否则锁在查询后立即释放
• AR 的 findOne() 返回对象后调用 $model->save()，底层走的是普通 UPDATE，不会复用之前查到的锁 —— 这是常见误解

为什么 ActiveRecord::update() 不带悲观锁

因为 ActiveRecord::update() 和 updateAll() 底层只拼 WHERE 条件执行 UPDATE，不感知事务锁状态，也不执行 SELECT 阶段。它没有“先查再锁再改”的语义，只是原子性写操作。即使你在事务里调用 $model->save()，也只保证写入的原子性，不保证读取时的数据独占性。

• 想在更新前确保数据未被他人修改，必须自己先 SELECT ... FOR UPDATE 查一次并保持事务打开
• $model->refresh() 会重新查库，但不加锁，无法替代 FOR UPDATE
• 若强行在 AR 中封装 FOR UPDATE，需重写 find() 方法并绑定事务，但违背 Yii 的设计习惯，易出错

实际 RESTful 场景中的典型写法（以订单扣库存为例）

假设接口是 PUT /api/items/123/lock，目标是锁定商品并预留库存。不能靠 AR 自动处理，得手写事务块：

$transaction = Yii::$app->db->beginTransaction();
try {
    // 关键：原生查询 + FOR UPDATE
    $row = Yii::$app->db->createCommand(
        'SELECT id, stock, version FROM item WHERE id = :id FOR UPDATE'
    )->bindValue(':id', $itemId)->queryOne();
if (!$row || $row['stock'] < 1) {
    throw new BadRequestHttpException('库存不足');
}

// 执行业务逻辑（如生成预订单、扣减库存）
Yii::$app->db->createCommand()->update('item', [
    'stock' => $row['stock'] - 1,
    'version' => $row['version'] + 1,
], ['id' => $itemId])->execute();

$transaction->commit();
return ['status' => 'locked', 'stock' => $row['stock'] - 1];
} catch (\Exception $e) {
$transaction->rollBack();
throw $e;
}

• 整个过程必须在单个事务内完成，不能拆成多个 HTTP 请求或多个 createCommand() 独立调用
• 如果接口是无状态的 RESTful，注意事务生命周期不能跨请求；锁只在当前请求内有效
• 高并发下 FOR UPDATE 可能导致请求排队等待，需监控锁等待时间（innodb_row_lock_time_avg）

真正难的不是写那句 FOR UPDATE，而是判断哪里该加、加多久、失败后怎么降级——比如超时自动放弃，或 fallback 到乐观锁重试。这些决策不在框架里，而在你的业务边界里。

理论要掌握，实操不能落！以上关于《Yii框架悲观锁实现全解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！