子查询必须用括号包裹，否则语法报错；关联子查询每行执行一次致性能差，应改用JOIN或CTE预计算；多值匹配须用IN/EXISTS而非=，标量子查询需确保单值返回。
子查询必须用括号包裹，否则语法直接报错
SQL里子查询不是加个 SELECT 就完事——它必须出现在圆括号中，否则数据库（比如 MySQL、PostgreSQL）会抛出 ERROR 1064 或类似语法错误。很多人写完 WHERE amount > SELECT AVG(amount) FROM transactions 发现报错，就是因为漏了括号。
常见写法错误：
-
WHERE amount > SELECT AVG(amount) FROM transactions→ 错误（缺括号） -
WHERE amount > (SELECT AVG(amount) FROM transactions)→ 正确 - 在
FROM子句中，子查询还必须带别名：FROM (SELECT dept, SUM(revenue) AS dept_rev FROM sales GROUP BY dept) AS dept_summary
关联子查询 vs 非关联子查询：性能差别极大
财务报表常要“每个部门的营收是否高于全公司平均”，这种需求容易写出关联子查询——即子查询里引用了外层表字段。它每行执行一次，数据量大时极慢。
例如：
SELECT dept, revenue FROM sales s1 WHERE revenue > ( SELECT AVG(revenue) FROM sales s2 WHERE s2.year = s1.year -- 这里引用了外层 s1.year，是关联子查询 );
更优做法是先算好年度平均值，再 JOIN：
- 用
WITH公共表表达式预计算：WITH yearly_avg AS (SELECT year, AVG(revenue) AS avg_rev FROM sales GROUP BY year) - 或把子查询改成非关联的、带
GROUP BY year的独立结果集，再通过JOIN关联 - 尤其在 Oracle 或旧版 MySQL 中，关联子查询几乎无法走索引，千万级数据可能卡住数分钟
子查询返回多行时，必须用 IN / EXISTS / ANY 而不是 =
财务场景中常要查“所有发生过退款的客户订单”，如果写成 WHERE customer_id = (SELECT customer_id FROM refunds)，只要退款记录超过一条，就报错 Subquery returns more than 1 row。
对应关系要严格匹配操作符：
- 单值比较（如
>,=）→ 子查询必须确定返回 1 行 1 列，可用LIMIT 1或聚合函数兜底 - 多值匹配 → 改用
IN：WHERE customer_id IN (SELECT customer_id FROM refunds) - 存在性判断（更高效）→ 用
EXISTS：WHERE EXISTS (SELECT 1 FROM refunds r WHERE r.order_id = o.id)，避免 NULL 值陷阱，且通常比IN快
嵌套三层以上子查询时，优先考虑 CTE 或临时表
做资产负债表或现金流量表时，有人会堆叠 SELECT * FROM (SELECT ... FROM (SELECT ...))，到第三层就开始难读、难调、难加索引。PostgreSQL 和 SQL Server 支持 WITH，MySQL 8.0+ 也支持，这是更干净的选择。
例如计算“各产品线调整后毛利”（需先算收入、再扣成本、再减返点）：
WITH revenue AS ( SELECT product_line, SUM(amount) AS rev FROM sales GROUP BY product_line ), cost AS ( SELECT product_line, SUM(amount) AS c FROM costs GROUP BY product_line ), rebate AS ( SELECT product_line, SUM(amount) AS rb FROM rebates GROUP BY product_line ) SELECT r.product_line, r.rev - COALESCE(c.c, 0) - COALESCE(rb.rb, 0) AS gross_margin FROM revenue r LEFT JOIN cost c ON r.product_line = c.product_line LEFT JOIN rebate rb ON r.product_line = rb.product_line;
CTE 不仅可读性强，还能被多次引用；而深层嵌套子查询一旦某一层字段名冲突或类型隐式转换出错，调试起来非常被动。
真正麻烦的是跨库或兼容老版本 MySQL（CREATE TEMPORARY TABLE 分步存中间结果，而不是硬扛四层括号。
