子查询中不能直接调用存储过程，因语义冲突：子查询需返回值，而存储过程执行动作、可能含多结果集或副作用；唯一兼容解法是先执行过程存入临时表/表变量，再参与查询。
子查询里不能直接调用存储过程
SQL 标准和主流数据库（MySQL、PostgreSQL、SQL Server）都明确禁止在 SELECT、WHERE、FROM 等子查询上下文中直接执行存储过程。这不是语法限制松紧的问题，而是语义冲突：子查询要返回结果集或标量值，而存储过程本质是执行动作，可能有多个结果集、输出参数、事务副作用，无法被当作“值”嵌入表达式。
常见错误现象：ERROR 1305 (42000): PROCEDURE db.proc_name does not exist（MySQL），或更隐蔽的 Invalid use of a side-effecting operator（SQL Server）。这些报错往往让人误以为是权限或路径问题，实际是语法越界。
- MySQL 中试图写
SELECT (CALL proc_a(1)) FROM t→ 直接语法错误 - SQL Server 中写
SELECT * FROM t WHERE id IN (EXEC proc_b @x=1)→ 编译失败 - PostgreSQL 中用
SELECT * FROM (CALL proc_c()) s→ 仅 v14+ 支持CALL作为语句，但不可嵌入子查询
想让存储过程结果参与查询？用临时表或表变量过渡
核心思路是把“过程执行”和“结果使用”拆成两步：先运行存储过程，把输出存到一个中间结构；再把这个结构当普通表 JOIN 或子查询。这是唯一跨数据库兼容的解法。
使用场景：需要基于存储过程生成的动态过滤条件做主查询，比如权限校验后返回可访问的订单 ID 列表，再查订单详情。
- MySQL：用
CREATE TEMPORARY TABLE tmp AS SELECT ...接收存储过程的INSERT ... SELECT输出（需过程内部显式插入） - SQL Server：声明
DECLARE @t TABLE(...)，用INSERT @t EXEC proc_d捕获单结果集（注意：过程不能含PRINT或多结果集） - PostgreSQL：改用函数替代存储过程，定义为
RETURNS TABLE(...)，就能直接SELECT * FROM func_e(1)嵌入子查询
性能影响明显：每次调用都触发一次完整过程执行 + 中间表 I/O，高并发下易成瓶颈。别在 WHERE 子句里对每行都跑一遍。
用函数替代存储过程？小心副作用和权限陷阱
如果存储过程逻辑纯计算、无事务/DDL/临时表，可重构成标量函数或表值函数。但函数受严格约束：MySQL 函数不能修改数据，PostgreSQL 的 STABLE/IMMUTABLE 函数不能调用随机或时间相关函数，SQL Server 表值函数不支持 EXEC。
容易踩的坑：
- MySQL 中定义
CREATE FUNCTION f() RETURNS INT BEGIN INSERT INTO log VALUES(NOW()); RETURN 1; END→ 创建失败，违反“函数不能修改数据”规则 - SQL Server 中用
SELECT * FROM t WHERE col = dbo.fn_with_exec(@x)→ 若函数内含EXEC，会报错Invalid use of a side-effecting operator - PostgreSQL 中函数默认以定义者权限运行，若调用者无底层表
SELECT权限，即使函数能执行，子查询也会因权限不足失败
嵌套调用本身不报错，但会让调试和事务失控
所谓“嵌套调用”，比如存储过程 A 内部 CALL B()，B 再 CALL C()。语法上多数数据库允许，但问题藏在运行时：事务边界模糊、错误传播断裂、堆栈深度难控。
典型症状：
- 过程 C 抛出异常，A 捕获不到，回滚只发生在 C 内部，A 继续执行 → 数据不一致
- MySQL 中嵌套过深触发
max_sp_recursion_depth限制，默认 0（禁用），设太高可能栈溢出 - SQL Server 中
SET XACT_ABORT ON在嵌套过程里行为复杂，外层事务可能被意外提交
真正麻烦的是日志和监控：你看到一条慢查询告警，但实际耗时分散在三层过程里，而 SQL 日志只记最外层语句。没有额外埋点，根本分不清是哪一层拖慢了。
