MySQL批量FOR UPDATE必须显式排序ID列表，因IN子句中ID顺序不一致会导致加锁顺序不同，引发循环等待死锁；GORM不自动重排，需在Go层调用sort.Ints(ids)确保锁序统一。
批量更新时直接用 IN 列表加锁，不排序就进事务，90% 会触发死锁。 根本原因不是 GORM 问题，而是 MySQL 的行锁顺序不可控 —— 它按索引物理顺序或优化器决定的扫描顺序加锁，不同 goroutine 锁同一组 ID 但顺序不同，就卡住了。
为什么批量 FOR UPDATE 必须显式排序？
MySQL 的 SELECT ... FOR UPDATE 在多行场景下，加锁顺序依赖查询执行计划。如果两个事务分别执行：
SELECT * FROM accounts WHERE id IN (5, 2) FOR UPDATESELECT * FROM accounts WHERE id IN (2, 5) FOR UPDATE
它们可能先锁 id=5 再锁 id=2，另一个反之，形成循环等待。GORM 不会自动帮你重排 IN 参数顺序 —— 它原样拼 SQL。
解决办法只有一个：在 Go 层把 ID 列表升序排序，再传给 Where("id IN ?", ids)。
Clauses(clause.Locking{Strength: "UPDATE"}) 的实际行为
这个 Clause 确实生成 FOR UPDATE，但它不改变 WHERE 条件顺序，也不保证锁顺序。常见误用：
- 用
Where("id IN ?", []int{3,1,4})→ SQL 中仍是IN (3,1,4)，MySQL 可能按 1→3→4 或 3→4→1 加锁 - 没开事务就加锁 → 锁立刻释放，毫无意义
- 混用
Find和First→Find返回切片，First只锁一行，批量场景必须统一用Find
正确写法示例：
sort.Ints(ids) // 必须先排序！
var accounts []Account
err := tx.Clauses(clause.Locking{Strength: "UPDATE"}).
Where("id IN ?", ids).
Find(&accounts).Error
批量更新失败后怎么重试才不翻车？
死锁错误是 mysql.ErrDeadlock（错误码 1213），不是普通超时或约束冲突。重试逻辑必须满足：
- 只对
mysql.ErrDeadlock重试，其他错误直接返回（比如余额不足、字段校验失败） - 每次重试前重新查询最新数据 —— 因为上一轮可能已部分提交，状态已变
- 限制重试次数（建议 ≤ 3 次），避免雪崩
- 不要在重试时复用旧的
tx对象 —— 必须新开事务
典型结构：
for i := 0; i < 3; i++ {
err := db.Transaction(func(tx *gorm.DB) error {
sort.Ints(ids)
var accounts []Account
if err := tx.Clauses(...).Where("id IN ?", ids).Find(&accounts).Error; err != nil {
return err
}
// 校验 & 更新逻辑
return tx.Save(&accounts).Error
})
if errors.Is(err, mysql.ErrDeadlock) {
continue // 重试
}
return err
}
乐观锁适合批量更新吗？
不适合。乐观锁靠 WHERE id = ? AND version = ? 做并发控制，批量更新意味着你要一次查出所有记录的当前 version，再一次性发 N 条带版本条件的 UPDATE。问题在于：
- 无法原子性保证这 N 行都成功 —— 其中某条失败，其余已更新，业务状态不一致
- 版本号冲突概率随行数线性上升，3 行可能还行，30 行基本必败
- 没有锁，但要反复读-改-写，网络和 CPU 开销反而更大
结论：批量更新强一致性场景，老实用悲观锁 + 排序；高并发低冲突的单行更新（如用户积分、订单状态），再考虑乐观锁。
最易被忽略的一点：排序必须在事务 开始前 做，且排序后的 ids 要全程透传到 Where，中间任何 map 转换、结构体赋值都可能打乱顺序。别信“GORM 会帮你理清”，它不会。
