根本原因是SQL执行方式未控制锁范围和事务时长；WHERE条件必须走主键或唯一索引，否则隐式转换或函数包裹字段会导致全表扫描并加锁。
Yii2 更新大表数据时锁表，根本原因不是“用了 Yii”，而是 SQL 执行方式没控制好锁范围和事务时长。直接调 updateAll() 或循环 save()，等于把 MySQL 的行锁风险全暴露给高并发场景。
WHERE 条件必须走主键或唯一索引
Yii2 的 updateAll() 本身不加锁，但一旦 WHERE 条件没命中索引，MySQL 就会全表扫描并逐行加记录锁+间隙锁——效果等同锁表。
- 常见失效场景：
status是VARCHAR类型，却写成['status' => 1]，触发隐式转换； - 用函数包裹字段，如
['DATE(create_time)' => '2026-07-28']，应改写为['>=', 'create_time', '2026-07-28']和['； - 前缀索引未覆盖查询值，比如索引是
INDEX(name(10))，但条件是['name' => 'verylongusername123']（超 10 字符）； - 执行前务必在 MySQL 中用
EXPLAIN SELECT id FROM table WHERE ...验证type不是ALL，rows远小于总行数。
分批更新必须用主键游标，禁用 OFFSET
Yii2 里写 Product::updateAll(['price' => new \yii\db\Expression('price * 1.1')], ['category' => 'Electronics']) 看似简洁，但若匹配百万行，就是一次长事务、大量锁堆积。
- 正确做法：先查 ID 列表，再按主键分批更新。例如：
SELECT id FROM product WHERE category = 'Electronics' ORDER BY id LIMIT 1000； - 然后用
updateAll(..., ['id' => $ids])，确保$ids是整数数组且非空； - 下一批起始点取上一批
MAX(id)，而不是LIMIT 1000 OFFSET 1000（后者越往后扫描越慢，还可能漏数据）； - 单批建议 ≤ 500 行；若字段大或涉及 JOIN，压到 ≤ 100 更稳妥。
事务必须显式控制，不能依赖框架自动提交
Yii2 默认开启 autocommit=1，但 updateAll() 是自动提交的——这会让每批更新后立即释放锁，看似安全，实则无法控制锁竞争节奏。真正可控的方式是手动事务 + 分批 + 延时。
- 每次分批前调用
$transaction = Yii::$app->db->beginTransaction()； - 执行
updateAll()后立刻$transaction->commit()； - 批次间加
usleep(10000)（10ms），缓解锁队列堆积和主从复制压力； - 避免在事务中混用
forUpdate()或LOCK IN SHARE MODE，它们会延长锁持有时间； - 使用连接池时，每批更新前建议重新获取连接（或执行
RESET CONNECTION），防止复用残留事务上下文。
多表更新必须统一加锁顺序
如果批量更新涉及 order、order_item、user_account 多张表，不同事务按不同顺序操作，死锁是确定性事件，不是概率问题。
- 所有业务代码必须约定唯一顺序，例如固定按表名字母序：
order_item → order → user_account； - 禁止根据业务类型动态拼接 SQL 顺序，比如
if ($type === 'refund') { update user first }； - 每张表的更新都必须基于主键或唯一索引，避免
SELECT ... FOR UPDATE升级为宽范围间隙锁； - 若某场景必须反向操作（如退款需先改订单再加库存），拆成两个独立事务，中间不跨锁，用最终一致性兜底。
最常被忽略的一点：锁表问题往往不是出在 Yii2 写法上，而是出在 MySQL 层没设 innodb_lock_wait_timeout（默认 50 秒），导致死锁报错后应用层不重试，直接崩。Yii2 里必须自己实现最多 3 次、带 50ms 间隔的重试逻辑，否则高并发下只要一碰就倒。
