子查询无法替代存储过程，因其缺乏事务控制、DML执行、变量定义、循环及异常处理等核心能力，仅适用于纯读取、无状态的单次计算场景。
不能用子查询替代复杂存储过程——这不是写法问题，而是能力边界问题。子查询没有事务控制、不能执行 DML、无法定义变量或循环，遇到需要分步提交、异常回滚或跨表校验的逻辑，硬塞进子查询只会导致语法报错或语义错误。
为什么子查询根本没法承担存储过程的职责
存储过程的核心能力（事务、DML、控制流）在 SQL 标准里被明确排除在子查询作用域外：
-
COMMIT、ROLLBACK、INSERT/UPDATE/DELETE语句在子查询中直接报错：ERROR: invalid transaction termination - 子查询不能声明变量、不能用
IF/FOR、不能捕获异常，所有流程控制必须由外层调用者（如应用或 CALL）驱动 - 哪怕只是“先查余额、够就扣款、更新日志”，子查询也做不到——它只能返回一个值或结果集，不能串起多步副作用操作
哪些“看起来像存储过程”的逻辑真能用子查询改写
只有纯读取、无状态、单次计算的场景才适合子查询化简，比如：
- 把一段重复的
SELECT ... FROM (WITH ...) s提炼成视图或 CTE，而非过程 - 将简单条件聚合（如“每个部门最高薪员工”）从过程体里抽出来，改用
LATERAL或窗口函数 - 用
VALUES+JOIN替代超长IN (SELECT ...)子查询，避免物化开销
注意：IN 子查询本身仍是子查询，不是存储过程替代方案；它只解决查询表达问题，不解决业务编排问题。
误以为“子查询能替代过程”的典型翻车点
开发者常把以下模式当成“简化”，结果引发数据不一致或执行失败：
- 在触发器里写
(SELECT pg_sleep(0.1))模拟延迟校验 → 触发器会卡住整个事务，且无法 rollback 到中间点 - 用
SELECT INTO试图在子查询里建临时表 → PostgreSQL 不允许子查询中出现INTO，报 ERROR: SELECT ... INTO is not allowed here - 把原本带
RAISE EXCEPTION的校验逻辑硬塞进WHERE EXISTS (SELECT ...)→ 错误被静默吞掉，约束失效
真正该做的，是把校验逻辑拆成 FUNCTION（返回 BOOLEAN 或抛错），再由存储过程或触发器调用；子查询只负责“算出什么”，不负责“决定怎么做”。
最易被忽略的是：存储过程里的 BEGIN ... EXCEPTION 块能局部捕获错误并继续执行后续语句，而子查询一旦出错，整个外层查询直接终止——这不是性能差异，是容错模型的根本不同。
