嵌套查询本身不能直接接收外部参数，所谓“动态过滤”必须靠上层容器（如存储过程）将变量透传至外层查询作用域；子查询无参数入口，其执行环境完全由外层SQL作用域决定，@param仅在外层WHERE或JOIN中有效，写入子查询内部会报错“Must declare the scalar variable”。
嵌套查询本身不能直接接收外部参数，所谓“动态过滤”必须靠上层容器（比如存储过程）把变量透传进去——不是嵌套查询变活了，而是你把它写进了能吃参数的上下文里。
SQL Server 中子查询无法直接引用存储过程参数
在 SELECT * FROM (SELECT ... ) AS t WHERE t.col = @param 这类写法里，@param 能用，是因为它处于外层查询作用域；但如果你把 @param 写进子查询内部（比如子查询里又套一层 SELECT 并试图 WHERE col = @param），只要该子查询是独立定义、未被外层显式关联，SQL Server 就会报 Must declare the scalar variable "@param"。
- 子查询不是函数，没有参数入口，它的执行环境完全由外层 SQL 的作用域决定
- CTE（
WITH）也一样：定义时不能带参数，WITH cte AS (SELECT ... WHERE col = @p)是合法的，因为@p来自外层；但你不能“调用”CTE 时传参 - 视图更彻底：连
@param都不允许出现在定义中，硬写就编译失败
真正可行的动态嵌套方式：把参数带到最外层 WHERE 或 JOIN 条件
多数人想实现的“动态嵌套”，其实是让内层结果受外层参数影响。正确做法不是让子查询自己认参数，而是让外层逻辑控制子查询的输入或筛选出口。
- 用
EXISTS或IN把参数留在外层条件中：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.status = @status) - 把参数传给内联表值函数（ITVF）替代子查询：
SELECT * FROM customers c JOIN dbo.fn_recent_orders(@days_back) o ON c.id = o.customer_id - 若必须用派生表（
FROM (SELECT ...) AS t），确保所有过滤都落在外层WHERE，别指望子查询自己“感知”参数
MySQL/PostgreSQL 的差异点：别默认它们和 SQL Server 一样
MySQL 5.7 不支持在子查询中直接引用外层变量（除非用 JOIN 关联或相关子查询），而 PostgreSQL 允许在 LATERAL 子查询中自然访问外层列——但依然不接受存储过程变量，除非你用 EXECUTE ... USING 动态拼。
- PostgreSQL 的
LATERAL可以让子查询“看到”外层字段，例如：SELECT c.name, o.total FROM customers c, LATERAL (SELECT SUM(amount) FROM orders WHERE customer_id = c.id AND status = $1) o，但$1必须来自 PREPARE 绑定，不是存储过程参数直传 - MySQL 中，相关子查询能引用外层列，但不能引用存储过程变量；想传参只能靠动态 SQL +
PREPARE/EXECUTE，且列名必须白名单校验 - 三者共通底线：对象名（表、列）、排序字段、分页偏移量这些都不能当参数绑定，必须拼接，且必须用
QUOTENAME()（SQL Server）、quote_ident()（PG）、正则过滤（MySQL）兜底
最容易被忽略的是：你以为嵌套查询“动”了，其实只是外层条件变了；真正的动态性来自存储过程如何组织语句结构，而不是子查询本身有多聪明。参数一旦没落到执行计划可感知的位置（比如外层 WHERE、JOIN ON、LATERAL 关联条件），优化器就无从下推，性能和语义都可能出偏。
