子查询必须用括号包裹，否则语法报错；单行子查询用于=、>等比较操作，多行需用in或exists；in遇null返回unknown，exists更安全高效；相关子查询易引发n+1性能问题，应优先用join或窗口函数；from中子查询必须加别名，且列名冲突时需用别名限定。
子查询必须用括号包裹，否则语法直接报错
SQL里子查询不是随便写个SELECT就能嵌进去的。它必须被一对圆括号包住，否则解析器会直接抛出ERROR: syntax error at or near "SELECT"这类错误。常见错误是把子查询当普通表达式用，比如写成WHERE user_id = SELECT id FROM admins——这肯定挂。
正确写法是：WHERE user_id = (SELECT id FROM admins WHERE role = 'super')。注意几个关键点：
- 单行子查询（返回一个值）才能用于
=、>这类比较操作符 - 如果可能返回多行，得换用
IN或EXISTS - 子查询里不能有
ORDER BY（除非配合LIMIT且外层是SELECT顶层）
IN 和 EXISTS 的选择直接影响性能和语义
IN看着简单，但遇到NULL就容易出意外：如果子查询结果包含NULL，整个IN判断会变成UNKNOWN，导致行被过滤掉——这常让开发者误以为数据丢了。
EXISTS更安全，也更适合关联场景：
SELECT * FROM orders o WHERE EXISTS ( SELECT 1 FROM users u WHERE u.id = o.user_id AND u.status = 'active' );
要点：
-
EXISTS只关心是否存在匹配行，不返回实际数据，通常比IN快（尤其子查询表大时） -
IN适合明确的值列表或小结果集，比如WHERE status IN (SELECT code FROM status_lookup) - MySQL 5.7+ 对
IN做了优化，但PostgreSQL里仍建议优先测EXISTS
相关子查询要警惕N+1性能陷阱
像SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = users.id) AS order_count FROM users这种写法，表面简洁，实则每查一行users，都执行一次子查询。1万用户 = 执行1万次orders扫描。
替代方案更稳：
- 改用
LEFT JOIN+GROUP BY，一次扫完两张表 - 用窗口函数（如
COUNT(*) OVER (PARTITION BY user_id)），但需确认数据库支持 - 真要用相关子查询，务必确保
orders.user_id上有索引
子查询别名在FROM子句中不可省略
当子查询出现在FROM里（俗称“派生表”），必须带别名，否则MySQL报Every derived table must have its own alias，PostgreSQL也拒绝解析。
正确写法：
SELECT u.name, t.total FROM users u JOIN (SELECT user_id, SUM(amount) AS total FROM payments GROUP BY user_id) AS t ON u.id = t.user_id;
注意：
- 别名
t不能省，哪怕只是临时用 - 子查询里的列名若和外层冲突，必须通过别名限定，比如
t.total - 这种子查询无法引用外层表字段（不支持相关），想关联得用
LATERAL（PostgreSQL）或改写为JOIN
子查询嵌套深了容易漏括号、搞混作用域，尤其是跨三层以上时，建议先单独跑子查询验证结果，再往主查询里粘——别信“应该没问题”。
