where中不能用case when替代原生布尔逻辑，因其无法下推、放弃索引导致全表扫描；应改用and/or组合或union all拆分，仅在物化为索引列时才可安全协同使用。

CASE WHEN 不能安全替代 WHERE 中的复杂条件，硬塞进去大概率导致性能崩盘或逻辑错乱。

WHERE 里写 CASE WHEN 为什么总出问题？

数据库优化器对 CASE WHEN 包裹的过滤条件基本“视而不见”——它无法推导索引使用路径，也难做谓词下推。比如写成 WHERE CASE WHEN status = 'A' THEN created_at ELSE updated_at END > '2026-01-01'，PostgreSQL 或 MySQL 都会放弃走 created_at 或 updated_at 上的索引，直接全表扫描。

• 错误现象：查询变慢几倍甚至几十倍，执行计划里出现 Seq Scan 或 Using where; Using filesort
• 本质原因：CASE WHEN 是表达式计算层逻辑，而 WHERE 需要的是可下推、可索引的原始谓词
• 唯一勉强能接受的例外：字段本身是动态派生的（如 CASE WHEN is_temp = 1 THEN temp_time ELSE base_time END），且无法提前物化为列

真正该用什么代替？

把条件拆回原生布尔逻辑，用 AND/OR 组合，让优化器自己选执行路径：

• 别写：WHERE CASE WHEN type = 'A' THEN amount > 1000 ELSE amount > 500 END
• 改写为：WHERE (type = 'A' AND amount > 1000) OR (type != 'A' AND amount > 500)
• 如果分支多，考虑用 UNION ALL 拆查询（尤其当各分支能命中不同索引时）
• 后台开关类需求（如“按日期范围或ID列表过滤”），交给应用层拼 SQL 或绑定参数，比如 WHERE created_at > ?，由代码传入不同值

哪些场景反而适合用 CASE WHEN 配合 WHERE？

不是替代，而是协同：用 CASE WHEN 先算出中间状态，再在 WHERE 里过滤这个状态——但必须确保该状态列可被索引（比如物化为生成列或提前建好索引）：

• PostgreSQL 12+ 可建表达式索引：CREATE INDEX idx_status_group ON orders ((CASE WHEN status IN ('A','B') THEN 'active' ELSE 'inactive' END));
• MySQL 8.0+ 支持函数索引：CREATE INDEX idx_grade ON students ((CASE WHEN score >= 90 THEN 'A' END));
• 否则，宁可重复写条件，也不要依赖 CASE 衍生列做过滤

最常被忽略的一点：你以为在 WHERE 里用 CASE WHEN 是为了“统一逻辑”，其实只是把性能问题和 NULL 处理风险一起打包藏起来了——查不出数据时，你得先分清是条件写错了，还是索引失效了，还是 ELSE 漏写导致整行被筛掉。