子查询不能直接替代case when，但可通过select、where或join组合实现等效逻辑；优先用case when处理同表字段判断，分支依据来自他表或聚合时才用标量子查询，并注意相关子查询、null陷阱、可读性及执行计划验证。
子查询不能直接替代 CASE WHEN，但能实现等效效果
SQL 标准里没有“子查询分支语句”这种东西，CASE WHEN 才是处理条件分支的正统方式。所谓“用子查询实现分支逻辑”，本质是把某个分支结果封装成独立查询，再通过 SELECT、WHERE 或 JOIN 引入主逻辑——不是语法支持分支，而是靠结构组合出分支行为。
常见误操作是写成这样：SELECT IF((SELECT COUNT(*) FROM orders WHERE user_id = 1) > 0, 'active', 'inactive')——看似分支，实则隐含性能风险：每次行计算都触发一次子查询，数据量大时 I/O 爆增。
- 优先用
CASE WHEN处理同一张表内的字段判断（如CASE WHEN status = 'paid' THEN 'confirmed' ELSE 'pending' END） - 当分支依据来自另一张表或聚合结果时，才考虑把该逻辑抽成子查询
- 子查询必须返回单值（标量子查询），否则会报错
Subquery returns more than 1 row
在 WHERE 中用标量子查询做动态阈值过滤
比如要查“订单金额高于该用户平均订单金额的订单”，不能写 WHERE amount > AVG(amount) GROUP BY user_id（语法非法），得把均值算出来作为动态阈值：
SELECT order_id, amount FROM orders o1 WHERE amount > ( SELECT AVG(amount) FROM orders o2 WHERE o2.user_id = o1.user_id );
这里的关键是子查询用了相关引用（o2.user_id = o1.user_id），每行订单都会触发一次对应用户的均值计算。注意：
- 子查询必须加别名（如
o2），否则相关列无法解析 - 如果某用户无历史订单，子查询返回
NULL，整行被过滤（> NULL恒为 false） - MySQL 8.0+ 可改用窗口函数
AVG(amount) OVER (PARTITION BY user_id)，性能更好且更直观
用 EXISTS 替代 IN 避免 NULL 导致的逻辑翻车
当分支逻辑是“是否存在满足某条件的记录”时，别用 IN (SELECT ...)，尤其子查询可能返回 NULL：
-- 危险！若 sub_table.id 含 NULL，则整个 NOT IN 永远不成立 SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM sub_table WHERE status = 'banned');
正确做法是用 NOT EXISTS，它对空集和 NULL 都有确定语义：
SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM sub_table s WHERE s.user_id = u.id AND s.status = 'banned' );
-
EXISTS只关心子查询是否返回至少一行，不取值，天然规避NULL陷阱 - 子查询中必须关联外层表（如
s.user_id = u.id），否则变成固定真假值 - 习惯写
SELECT 1而非SELECT *，语义清晰且数据库优化器更容易跳过字段解析
多层子查询嵌套时，别让可读性失控
三层以上子查询（比如 SELECT ... FROM (SELECT ... FROM (SELECT ...))）会让维护者抓狂。实际开发中更推荐拆解：
- MySQL 5.7+ / PostgreSQL / SQL Server 支持 CTE，用
WITH把每层逻辑命名，例如：WITH user_stats AS (...), qualified_users AS (...) - 临时表（
CREATE TEMPORARY TABLE）适合中间结果需多次引用的场景 - 视图（
CREATE VIEW）适合跨多个查询复用的稳定逻辑 - 如果子查询只用一次且很短（如
(SELECT MAX(created_at) FROM logs)），保留也无妨
最常被忽略的是执行计划验证：哪怕语法跑通，也要用 EXPLAIN 看子查询是否被物化（Materialized）或重复执行——这比写法本身更能决定性能生死。
