批量扣减余额须分页切片执行并加索引，禁用LIMIT分页，配合事务、FOR UPDATE锁及余额非负约束，确保原子性与数据安全。
子查询 WHERE 条件必须先 SELECT 验证
直接在 UPDATE 的 WHERE 中嵌套子查询，容易因逻辑错误或数据变化导致误扣减。比如你想从用户余额中批量扣减订单金额，但子查询返回了不该参与计算的用户 ID，整条语句执行后就不可逆了。
正确做法是把子查询单独拿出来跑一遍：SELECT user_id, amount FROM orders WHERE status = 'pending' AND created_at 。确认返回的 <code>user_id 数量、范围、金额总和都符合预期，再用于后续更新。
特别注意：子查询若涉及多表关联或聚合（如 SUM()），必须检查是否因 GROUP BY 缺失或 NULL 值被忽略而少选行。
UPDATE + 子查询必须显式加事务并设隔离级别
MySQL 默认的 REPEATABLE READ 在并发场景下可能让两次读取看到不同快照，导致同一笔余额被重复扣减。必须用 BEGIN TRANSACTION 显式开启，并推荐搭配 SELECT ... FOR UPDATE 锁住目标行。
示例结构：
START TRANSACTION; SELECT balance FROM users WHERE id IN ( SELECT user_id FROM orders WHERE status = 'pending' ) FOR UPDATE; UPDATE users u JOIN ( SELECT user_id, SUM(amount) AS total_deduct FROM orders WHERE status = 'pending' GROUP BY user_id ) o ON u.id = o.user_id SET u.balance = u.balance - o.total_deduct WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'pending'); COMMIT;
要点：
-
FOR UPDATE必须在UPDATE前执行，且作用于最终要更新的主表（users） - 子查询中的
orders表不能加FOR UPDATE，否则可能引发死锁 - 避免在子查询里用
ORDER BY或LIMIT，它们在UPDATE中不生效且易误导逻辑
扣减前必须校验余额是否充足
单纯 SET balance = balance - X 不检查负数，线上曾有因浮点精度或并发竞争导致余额为负的事故。
安全写法有两种：
- 用
CASE WHEN拦截：SET balance = CASE WHEN balance >= o.total_deduct THEN balance - o.total_deduct ELSE balance END - 更推荐加检查约束：
ALTER TABLE users ADD CONSTRAINT chk_balance_nonnegative CHECK (balance >= 0)，配合事务自动回滚 - 如果业务允许“透支”，也要明确记录透支标识，而不是靠负余额隐式表达
大批次扣减要分页避免锁表过久
一次性处理几万行订单，会持有 FOR UPDATE 锁太久，阻塞其他读写。实际生产中应按 user_id 或时间范围切片。
例如每次只处理 500 个用户：
UPDATE users u JOIN ( SELECT user_id, SUM(amount) AS total_deduct FROM orders WHERE status = 'pending' AND user_id BETWEEN 1000 AND 1499 GROUP BY user_id ) o ON u.id = o.user_id SET u.balance = u.balance - o.total_deduct WHERE u.id BETWEEN 1000 AND 1499;
关键细节：
- 切片字段必须有索引，否则
BETWEEN会全表扫描 - 不要用
LIMIT分页，它在UPDATE中不保证顺序，可能漏行或重叠 - 每批执行后加
COMMIT，释放锁；失败则记录断点，避免重试时重复扣减
最常被忽略的一点：子查询里的 orders 表状态变更（比如另一进程把订单改成了 paid）和主表 users 的锁不是原子绑定的——必须靠事务+锁+校验三者闭环，缺一不可。
