SQL子查询不改变其声明式本质，仅扩展表达能力；它描述“要什么”而非“怎么算”，引擎可自由优化执行方式，用户无需关心执行顺序。
SQL子查询不是“转向逻辑处理”的标志，恰恰相反——它强化了SQL作为声明式语言的本质：你描述“要什么”，而不是“怎么算”。所谓“逻辑处理”是误读，真实情况是子查询让声明更精确、更贴近业务语义。
子查询不改变声明式本质，只扩展表达能力
SQL本身不提供循环、赋值、顺序执行等过程式构造。子查询仍是一个完整 SELECT 语句，嵌套后依然只回答“哪些行满足条件”，而非“先查A再用结果查B”的执行步骤。数据库引擎有权重写、扁平化、甚至转为等价 JOIN 执行——用户无需（也不应）关心这个过程。
- 写
WHERE id IN (SELECT id FROM orders WHERE status = 'shipped')，你没指定“先跑内层再比对”，只是声明“取所有发货订单的id对应的记录” - 写
SELECT name, (SELECT MAX(price) FROM items WHERE category = p.category)，你没要求“对每行p都重新执行一次子查询”，只是声明“每个品类的最高价” - 引擎可能把后者优化成窗口函数或哈希连接，但SQL语句本身不暴露这些细节
相关子查询最容易让人误解为“过程执行”
像 WHERE x > (SELECT AVG(y) FROM t2 WHERE t2.id = t1.id) 这类相关子查询，因引用外部表字段，看起来像“为每一行t1调用一次子查询”。但这仍是声明式：你只定义了“x必须大于同id下t2中y的平均值”，而非“循环t1、每次执行一次子查询”。
- 实际执行时，SQL Server 可能将它重写为
LEFT JOIN+ 聚合，避免逐行求值 - 若子查询未被优化，性能会差，但这属于实现缺陷，不是语言设计意图
-
EXISTS子查询更典型：它只返回布尔值，引擎可提前终止扫描，完全不依赖“执行次数”概念
真正混淆声明式与过程式的，是UDF和游标，不是子查询
当你在 WHERE 中调用一个 dbo.GetCategoryName(id) 标量函数，或用 DECLARE @cur CURSOR 遍历结果集，才真正引入了过程式控制流。子查询从不引入状态、顺序依赖或副作用。
-
IN、EXISTS、=后的子查询，全部是纯表达式，无执行顺序约束 - 多层嵌套如
(SELECT ... FROM (SELECT ... FROM ...))，仍是单次声明求值，不是“先算里层再传给外层”的栈式调用 - SQL标准从未规定子查询执行时机，只规定语义等价性——这是声明式语言的核心契约
子查询的“结构化”体现在它允许你把复杂条件拆解为可读的逻辑单元，而不是执行模型的转变。容易被忽略的是：一旦你开始思考“这个子查询会被执行几次”，你就已经在用过程式思维误读SQL——而问题往往出在缺少索引或未触发查询重写，不是子查询本身有问题。
