子查询参数传递本质是数据依赖而非变量赋值，相关子查询逐行执行并引用外部字段，非相关子查询仅执行一次；必须确保标量子查询单行单列，多值匹配应改用in或exists，优先索引关联字段并用exists替代in以规避null与性能问题。
子查询参数传递本质是数据依赖，不是变量赋值
SQL里没有“参数传递”这个动作，所谓“在不同表间传递参数”，实际是用子查询结果作为外层查询的过滤条件或计算输入。关键在于理解子查询的执行时机和作用域：相关子查询（含外部表字段）会为外层每一行重复执行，而非相关子查询只执行一次。
常见错误是误以为 SELECT * FROM orders WHERE customer_id = (SELECT id FROM customers WHERE name = 'Alice') 中的子查询能“传参”给多行匹配——它只返回单值，若子查询结果多于一行，直接报错 Subquery returns more than 1 row。
- 必须确保非相关子查询只返回
1行1列，否则加LIMIT 1或用聚合函数如MAX() - 要用多行匹配，改用
IN或EXISTS，例如WHERE customer_id IN (SELECT id FROM customers WHERE city = 'Beijing') - 相关子查询中，外部表字段（如
orders.customer_id）只能在子查询的WHERE或HAVING中引用，不能出现在子查询的SELECT列表里用于“传出”
用 EXISTS 替代 IN 避免 NULL 和性能陷阱
当子查询涉及可空字段或大数据量时，IN 容易出问题：如果子查询结果包含 NULL，整个 IN 判断恒为 UNKNOWN，导致外层无结果返回；且 IN 通常需物化全部子查询结果，内存和速度都吃紧。
EXISTS 是更安全、更高效的选择，它只关心是否存在匹配行，不取值、不判 NULL，还能利用索引。
- 写法：
SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active') - 子查询里的
SELECT 1是惯例，内容无关紧要，数据库不会真正取这列值 - 注意关联条件必须写在子查询内部（如
c.id = o.customer_id），不能靠外层WHERE连接 - 若子查询中漏写关联条件，会变成笛卡尔积，性能崩盘
JOIN 比子查询更直观，但不等价于所有场景
多数“跨表传参”需求，用 JOIN 更清晰、性能更好。但要注意：子查询能表达的逻辑，JOIN 不一定直接对应。
例如，查“每个订单的客户等级”，用子查询可直接嵌入 SELECT 列表：SELECT id, (SELECT level FROM customers WHERE id = orders.customer_id) AS cust_level FROM orders。换成 JOIN 就得先去重或处理一对多关系。
- 一对一关系优先用
JOIN，避免重复子查询开销 - 需要标量子查询（返回单值）做计算字段时，子查询不可替代
-
LEFT JOIN+ 子查询组合可能产生意外NULL，而相关子查询天然支持NULL安全的条件判断 - MySQL 8.0+ 支持 CTE，复杂嵌套可用
WITH拆解，比多层子查询易读
MySQL 8.0+ 的 WITH RECURSIVE 处理层级参数传递
真正需要“参数传递”的典型场景是树形结构遍历，比如查某个部门的所有下级部门。这时靠普通子查询做不到，必须用递归CTE。
递归部分会把上一层的结果当作“参数”输入下一层，形成自引用链。
- 基础结构：
WITH RECURSIVE dept_tree AS (SELECT id, name, parent_id FROM departments WHERE id = 1 UNION ALL SELECT d.id, d.name, d.parent_id FROM departments d INNER JOIN dept_tree dt ON d.parent_id = dt.id) - 初始查询（
WHERE id = 1）相当于传入根节点ID，后续每次递归都用前次结果的id去查子节点 - 必须有终止条件（比如
depth ），否则可能无限循环 - PostgreSQL 用
WITH RECURSIVE类似，但语法细节不同；旧版 MySQL 不支持，只能用存储过程模拟
跨表参数传递不是语法糖，而是数据关系建模的体现。写子查询时，先问自己：这个“参数”到底代表什么业务含义？是筛选条件、计算因子，还是层级路径？答案不同，实现方式就完全不同。
