WHERE中不能直接用CASE WHEN做布尔分支，因多数数据库执行计划易退化、可读性差；应改用布尔逻辑显式拼接，如(:mode = 'active' AND end_date IS NULL) OR (:mode = 'done' AND end_date IS NOT NULL)，并注意NULL处理与类型兼容。
WHERE里不能直接用CASE WHEN做布尔分支？改用布尔逻辑组合
想在WHERE里根据参数值切换过滤条件（比如:mode = 'active'时查未结束订单，'done'时查已完结），别硬套CASE WHEN ... THEN condition END——多数数据库虽语法允许（如PostgreSQL支持(CASE WHEN ... THEN true ELSE false END)），但执行计划常退化，且可读性差、难调试。
真正稳定的做法是用布尔逻辑显式拼接：
WHERE (:mode = 'active' AND end_date IS NULL) OR (:mode = 'done' AND end_date IS NOT NULL AND end_date- 所有分支必须加括号，避免
AND/OR优先级干扰；尤其当混用NOT时，不加括号极易漏匹配 - 参数为NULL时整段条件可能失效，建议前置判断：
WHERE COALESCE(:mode, '') IN ('active', 'done') AND (...)
需要多层嵌套判断？先在子查询里算出标志列再过滤
当分支逻辑涉及聚合、跨表关联或需复用计算结果（比如“VIP用户中近7天有退款的标high_risk，否则标high”），直接在WHERE里写嵌套CASE会失控。此时应把判断下沉到子查询或CTE中，生成一个明确的标志字段，外层只做简单等值过滤。
例如：
SELECT * FROM (
SELECT
u.id,
u.total_amount,
CASE
WHEN EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = u.id) THEN 'blocked'
WHEN u.total_amount >= 10000 THEN
CASE
WHEN EXISTS (SELECT 1 FROM refund r WHERE r.user_id = u.id AND r.create_time > NOW() - INTERVAL '7 days')
THEN 'high_risk'
ELSE 'high'
END
ELSE 'low'
END AS label
FROM users u
) t WHERE t.label = 'high_risk';- 外层
WHERE只对label做字符串比较，不参与复杂逻辑计算 - 内层
CASE各分支返回统一类型（全为TEXT），避免隐式转换导致排序/分组异常 - 若
label用于GROUP BY，必须出现在子查询的SELECT列表中，否则报错column must appear in the GROUP BY clause
EXISTS比IN更适合做布尔型嵌套判断
嵌套查询中需要“是否存在满足某条件的记录”作为分支依据时（如“是否在黑名单”“是否近30天有支付”），优先用EXISTS而非IN子查询。它天然返回布尔值，语义清晰，且对NULL和类型不一致更鲁棒。
-
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')→ 安全，不关心o.user_id是否为NULL -
u.id IN (SELECT user_id FROM orders WHERE status = 'paid')→ 若user_id列含NULL，整条IN表达式判为UNKNOWN，该行被过滤掉 - MySQL 8.0+ 和 PostgreSQL 都对
EXISTS有较好优化，而IN (SELECT ...)在PostgreSQL中默认不转SEMI JOIN，易触发外层全表扫描
动态SQL条件拼接时，CASE WHEN只能当“开关”，不能当“条件体”
在应用层拼接SQL或使用数据库端参数化查询（如PostgreSQL的:param）时，CASE WHEN唯一安全的用法是控制某个字段是否参与比较，而不是把整个WHERE条件塞进去。比如按部门ID是否为空决定是否加department_id过滤：
AND CASE WHEN :dept_id IS NOT NULL THEN department_id = :dept_id ELSE TRUE END
- 注意
ELSE TRUE，不是ELSE 1=1（虽等效但易被误读） - 不能写成
CASE WHEN :dept_id IS NOT NULL THEN department_id = :dept_id END——漏ELSE会导致该条件为NULL，整行被过滤（三值逻辑下NULL AND ...结果为UNKNOWN） - 这种写法本质是“让条件恒真”，不是“跳过条件”，所以仍需确保字段类型兼容（如
:dept_id为INT，department_id不能是VARCHAR）
最易被忽略的是：布尔逻辑切换看似只是语法选择，实则牵动执行计划、NULL处理、类型推导三层。哪怕一个括号位置不对，或漏写ELSE TRUE，都可能让线上查询从毫秒级变成分钟级，且难以复现。
