case when写在select中不影响索引使用，仅作结果计算；出现在where或order by中则极易导致索引失效，应拆解为or/and条件或预计算字段。
CASE WHEN 写在 SELECT 列表里，一般不影响索引使用
只要 CASE WHEN 不出现在 WHERE、JOIN ON 或 ORDER BY 等驱动执行计划的子句中，它就只是结果计算逻辑，优化器根本不会拿它去选索引。这时候你加不加索引、加什么索引，跟 CASE WHEN 没关系。
常见误操作是看到查询慢，顺手把 CASE WHEN 改来改去，其实瓶颈压根不在那儿。
- ✅ 安全写法：
SELECT id, name, CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END FROM users; - ❌ 错误归因：这条语句慢，就去调
CASE的分支顺序或加括号——没用，得看WHERE status = 1有没有走索引
WHERE 中用 CASE WHEN，99% 导致索引失效
MySQL、PostgreSQL、SQL Server 都不擅长对 CASE WHEN 表达式做索引下推。一旦你写成 WHERE CASE WHEN x > 0 THEN y ELSE z END = 'val'，基本等于放弃索引扫描，退化为全表扫描。
真正要走索引，得把逻辑“外提”到可索引列上：
- ? 避免：
WHERE CASE WHEN category = 'A' THEN price ELSE cost END > 100 - ✅ 拆解：
WHERE (category = 'A' AND price > 100) OR (category != 'A' AND cost > 100) - ⚠️ 注意：OR 可能触发松散索引扫描（MySQL）或位图合并（PG），需结合
EXPLAIN看实际type和rows
想让 CASE WHEN 字段走索引？建函数索引（不是所有库都支持）
PostgreSQL 和 MySQL 8.0+ 支持基于表达式的索引，但必须和查询中写的表达式完全一致，且不能带不确定函数（如 NOW()、RAND()）。
例如想加速 WHERE CASE WHEN deleted = 1 THEN NULL ELSE id END = 123：
- ? PostgreSQL：
CREATE INDEX idx_active_id ON t ((CASE WHEN deleted = 1 THEN NULL ELSE id END)); - ? MySQL 8.0+：
CREATE INDEX idx_active_id ON t ((CASE WHEN deleted = 1 THEN NULL ELSE id END)); - ❌ SQLite / SQL Server 不支持函数索引（SQL Server 有计算列+索引变通方案）
- ? 验证是否命中：执行
EXPLAIN，确认key字段显示该索引名，且Extra不含Using where（表示过滤已下推）
ORDER BY + CASE WHEN 是隐形性能杀手
即使你建了函数索引，ORDER BY CASE WHEN ... 仍大概率无法利用它排序，因为索引顺序和 CASE 运行时结果不匹配。优化器宁可走索引查出全部数据再内存排序（Using filesort）。
更现实的解法是预计算：
- 加一个持久化计算列（MySQL 8.0+
STORED，PGGENERATED ALWAYS AS ... STORED） - 在应用层或定时任务里把分类逻辑固化到新字段，然后
ORDER BY new_sort_field - 如果只是分页展示，考虑用
UNION ALL分开查再合并（适合分支少、数据倾斜明显场景）
函数索引对 ORDER BY 的支持非常脆弱，哪怕多一个空格、换一种写法，都可能让优化器弃用索引。
