子查询中写o.id报错是因为未显式限定表别名，SQL禁止自动上溯访问外层字段，必须写成t1.id等带别名的完整形式；所有主流数据库均强制要求显式前缀，否则触发Unknown column错误。
子查询里写 o.id 为什么报错 “Unknown column”
不是语法写错了，而是没加表别名前缀。SQL 不允许子查询“自动上溯”识别外层字段，必须显式写成 t1.id 这种带别名的形式——哪怕外层只有一张表，也得写全。
常见错误现象：ERROR 1054 (42S22): Unknown column 'orders.customer_id' in 'where clause'，本质是子查询里写了 customer_id 却漏了 orders. 前缀。
- MySQL、PostgreSQL、SQL Server 全部要求显式限定，不能省略别名
- 如果外层用了
AS u，子查询里就得用u.id，不能用users.id（除非没设别名） - 别名遮蔽很危险：子查询里若也定义了
AS o，再写o.id就会指向子查询内部的o，而不是外层的
WHERE EXISTS 里怎么传外层字段
这是最典型、最安全的传递方式：把外层字段直接写进子查询的 WHERE 条件中，且必须是等值关联。
示例：SELECT c.name FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id)。这里 c.id 就是外层字段，它出现在子查询的 WHERE 中，且和子查询内表字段构成连接条件。
- 子查询的
SELECT部分（如SELECT 1）不参与字段传递，纯属占位 - 关联字段必须有索引，否则每行都触发全表扫描，性能爆炸
- 不能写成
o.customer_id = c.id AND o.status IS NOT NULL这类附加条件来“过滤外层”，那是逻辑错误——EXISTS只关心是否存在，附加条件只会让匹配变难，不是筛选外层
在 SELECT 列表里用标量子查询传参
这种写法能为每一行动态计算一个值，但限制极多：子查询必须返回 0 或 1 行、1 列，否则直接报错 Subquery returns more than 1 row。
示例：SELECT u.name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = u.id) AS order_count FROM users u。这里的 u.id 就是外层字段，被“传入”子查询的 WHERE 条件。
- MySQL 5.7 对嵌套层级敏感，太深可能报错；MySQL 8.0+ 和 PostgreSQL 更宽松
- PostgreSQL 推荐用
LATERAL替代，语义更清晰：SELECT u.name, o.cnt FROM users u LEFT JOIN LATERAL (SELECT COUNT(*) AS cnt FROM orders WHERE orders.user_id = u.id) o ON true - 千万别在标量子查询里加
ORDER BY或LIMIT——它们不被标准允许，部分数据库虽支持但行为不可靠
为什么 FROM 里的子查询不能用外层字段
因为它是派生表（derived table），作用域完全隔离。写成 FROM (SELECT * FROM orders WHERE user_id = users.id) t 会报错，users.id 在子查询作用域外不可见。
这是硬性规则，不是版本差异。所有主流数据库（MySQL、PostgreSQL、SQL Server）都如此。
- 想实现类似效果，必须改写为
JOIN或LATERAL（PostgreSQL）或APPLY（SQL Server） - MySQL 8.0+ 会尝试把简单相关子查询自动转成
JOIN，但仅限于IN+ 单列等特定结构，别依赖它 - 如果真需要从
FROM出发做关联，优先考虑 CTE 或临时表分步处理，比强行嵌套更可控
真正容易被忽略的是作用域层级：子查询只能看到直接父查询的字段，跨两层就失效；还有空值陷阱——IN 遇到子查询返回 NULL 会整个条件失效，而 EXISTS 完全免疫。
