子查询必须用于WHERE或SET中才生效，需注意并发安全、性能优化及事务锁机制。应使用SELECT FOR UPDATE加锁、临时表替代嵌套子查询、变量校验并配合SIGNAL抛错，同时保障业务幂等性。
子查询必须用在 WHERE 或 SET 中才能生效
直接写 SELECT * FROM accounts WHERE balance > (SELECT SUM(amount) FROM deductions) 看似合理，但实际校验逻辑往往更严：比如“扣款后余额不能低于 100 元”。这时候得把子查询嵌进计算表达式里，而不是只当过滤条件。常见错误是写成 UPDATE accounts SET balance = balance - (SELECT ...) 却没加 WHERE 限制行，结果全表误扣。
- 扣款前必须先查出当前余额和待扣总额，建议用单条语句完成：用
(SELECT balance FROM accounts WHERE id = 123)和(SELECT COALESCE(SUM(amount), 0) FROM pending_deductions WHERE account_id = 123)同时出现在同一SELECT的字段列表中，避免两次查询间余额被并发修改 - 子查询返回多行会报错
Subquery returns more than 1 row，务必加LIMIT 1或用聚合函数（如MAX()、COALESCE(SUM(), 0)）兜底 - MySQL 8.0+ 支持 CTE，比嵌套子查询可读性高很多，但老版本只能靠多层括号，注意括号配对——漏一个就语法报错
You have an error in your SQL syntax
事务不是加了 BEGIN 就安全，得配 SELECT FOR UPDATE
光靠 BEGIN; UPDATE ...; COMMIT; 挡不住并发扣款。两个事务同时读到余额 500 元，各自扣 300 元，最终变成 -100 元。真正起作用的是在 UPDATE 前显式锁定行：SELECT balance FROM accounts WHERE id = 123 FOR UPDATE。这条语句会阻塞其他事务对该行的 FOR UPDATE 或 UPDATE，直到本事务结束。
-
FOR UPDATE必须在事务内执行，且不能放在子查询里（MySQL 不允许子查询中使用锁定读） - 如果校验逻辑涉及多张表（如账户表 + 额度规则表），要按固定顺序加锁，否则可能引发死锁；建议总是先锁
accounts，再锁deduction_rules - PHP/Python 等应用层调用时，别用
autocommit=True，否则FOR UPDATE立即释放，锁失效
嵌套子查询性能崩在 JOIN 被隐式转成子查询时
你以为写了 UPDATE a SET balance = a.balance - d.total FROM accounts a JOIN (SELECT account_id, SUM(amount) total FROM deductions GROUP BY account_id) d ON a.id = d.account_id 很高效？在 MySQL 5.7 及更早版本里，优化器很可能把它重写成等价的关联子查询，导致每行都执行一次子查询。实测 10 万账户扣款，耗时从 200ms 涨到 12s。
- 用
EXPLAIN FORMAT=JSON查看执行计划，重点看"select_type": "DEPENDENT SUBQUERY"—— 出现这个就是性能雷区 - 替代方案：先把聚合结果写入临时表
CREATE TEMPORARY TABLE tmp_ded AS SELECT ...，再用JOIN tmp_ded更新，稳定可控 - PostgreSQL 用户注意：
UPDATE ... FROM语法原生支持，无需子查询，但 MySQL 不支持，硬要用就得改写成带子查询的 UPDATE + WHERE
校验失败时不能只靠 ROLLBACK，得返回明确错误码
业务系统需要知道是“余额不足”还是“规则不匹配”，但 SQL 层没法直接抛业务异常。常见做法是在事务里用变量承接校验结果：SET @can_deduct = IF((SELECT balance FROM accounts WHERE id = 123) >= (SELECT SUM(amount) FROM deductions WHERE account_id = 123), 1, 0);，再用 IF @can_deduct = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient balance'; END IF;。
-
SIGNAL是 MySQL 5.5+ 特性，低版本只能靠应用层判断SELECT结果再决定是否执行UPDATE - 不要在子查询里写 SIGNAL，MySQL 不允许子查询中包含流程控制语句
- 哪怕校验通过，UPDATE 影响行数为 0 也要检查——可能是 WHERE 条件没命中，不是数据问题而是参数传错了
真实场景里最麻烦的从来不是语法，而是“扣款成功但通知没发出去”或者“日志记了扣款但事务回滚了”。校验逻辑写得再密，也得配合幂等接口和补偿任务，不然数据库再稳，业务也是裸奔。
