子查询必须用括号包裹，且需根据位置（SELECT/ FROM/ WHERE等）匹配类型（标量、行、表），正确选用IN/= /EXISTS操作符，并谨慎处理NULL与关联性能问题。
子查询必须用括号包裹，否则语法直接报错
SQL 解析器把子查询当作一个独立表达式处理，不加括号会被当成语法错误。比如 WHERE id IN SELECT id FROM users WHERE active = 1 会报 ERROR: syntax error at or near "SELECT"。
- 正确写法是
WHERE id IN (SELECT id FROM users WHERE active = 1) - 即使子查询只返回单个值（如标量子查询），括号也不能省，
WHERE salary > (SELECT AVG(salary) FROM employees)是合法的，去掉括号就失效 - 嵌套多层时每层都要独立括号：
(SELECT name FROM departments WHERE id = (SELECT dept_id FROM employees WHERE id = 100))
IN、EXISTS、= 这三种操作符对子查询的要求完全不同
选错操作符会导致结果为空、性能骤降，甚至查出意外数据。
-
IN要求子查询返回**单列多行**，且不能含NULL—— 如果子查询结果里有NULL，整个IN判断会变成UNKNOWN，该行被过滤掉 -
=（或）只能用于**标量子查询**（必须且仅返回一行一列），否则报错ERROR: more than one row returned by a subquery used as an expression -
EXISTS只关心子查询是否返回至少一行，不关心内容，且支持关联（correlated）—— 它能天然规避NULL问题，也更适合大数据量下的存在性判断
关联子查询性能差，但有时不可替代
关联子查询（即子查询里引用了外部查询的列）每次外层行都会执行一次，容易成为性能瓶颈。
- 例如
SELECT name FROM orders o WHERE amount > (SELECT AVG(amount) FROM orders WHERE user_id = o.user_id)，外层每扫一条订单，内层就重算一次该用户的平均值 - 如果外层数据量大（比如百万级订单），建议先用
JOIN + GROUP BY预聚合，再关联，而不是硬扛关联子查询 - 但有些逻辑没法改写：比如“找出每个部门薪资最高的员工”，用窗口函数更优，但若数据库不支持（如旧版 MySQL），关联子查询仍是唯一可靠写法
子查询位置决定它能做什么
不是所有地方都能塞子查询，不同位置对子查询类型和用途限制很明确。
- 在
SELECT列表中：只能是标量子查询，比如SELECT id, (SELECT COUNT(*) FROM logs WHERE log.user_id = users.id) AS log_count FROM users - 在
FROM子句中：必须起别名，且行为类似临时表，比如SELECT * FROM (SELECT user_id, MAX(created_at) FROM events GROUP BY user_id) AS last_event - 在
WHERE或HAVING中：可标量、行、表子查询，但需匹配操作符语义（见上一条） - 不能出现在
GROUP BY或ORDER BY的表达式里（除非是标量子查询且确定可执行）
子查询看着简单，但括号、操作符、位置、NULL 处理这四点任意一个没对齐，结果就可能静默出错 —— 尤其是生产环境里数据含 NULL 或子查询实际返回多行却误用了 = 时，很难一眼发现。
