case when破坏统计信息可推导性，导致优化器无法复用原列直方图估算基数，引发执行计划误判；嵌套或函数进一步放大偏差，且视图中无法通过analyze修复，最终造成连接算法错误、索引失效或全表扫描。
视图中CASE WHEN破坏统计信息可推导性
SQL优化器估算基数（即预估返回行数）主要依赖列上的直方图、索引统计和确定性表达式。而CASE WHEN是运行时计算逻辑，它把原始列值映射为新值或新分组，这个映射关系无法被统计信息覆盖——优化器看不到“status = 'paid'”和“CASE WHEN status = 'paid' THEN 1 END”在分布上的一致性，也就无法复用原列的直方图做基数估计。
典型表现是执行计划里出现 Cardinality feedback 警告，或预估行数变成固定值（如100、1000），远偏离真实数据量，进而导致选错连接算法、忽略并行、甚至放弃使用索引。
CASE WHEN嵌套或配合函数进一步放大估算偏差
一旦CASE WHEN里混入COALESCE、CAST、字符串拼接或子查询，优化器基本放弃推导：它无法判断结果是否为空、是否重复、是否与原列存在函数依赖关系。
- 例如：
CASE WHEN COALESCE(email, '') != '' THEN 'has_email' ELSE 'no_email' END——COALESCE让空值处理不可见，优化器无法知道has_email占比 - 再如：
CASE WHEN SUBSTR(phone, 1, 3) IN ('138', '139') THEN 'mobile' END—— 函数截取破坏了原始phone列的统计分布
视图定义固化加剧问题，且无法通过ANALYZE修复
视图只是保存SQL文本，不存储中间结果或统计快照。即使你对基表执行了ANALYZE或更新了统计信息，优化器仍需在每次查询视图时重新解析整个CASE WHEN逻辑，而它没有缓存该表达式的输出分布。
这意味着：
- 你不能对视图中的
CASE WHEN结果列创建统计信息（比如PostgreSQL的CREATE STATISTICS不支持表达式列） - SQL Server的基数反馈（Cardinality Feedback）机制在视图场景下常失效，因为反馈基于实际执行，而视图重写可能改变执行路径
- Oracle的动态采样（Dynamic Sampling）对深层嵌套的
CASE WHEN效果有限，尤其当分支条件涉及多列关联时
真正影响性能的不是CASE WHEN本身，而是它引发的连锁反应
很多人以为慢是因为CASE WHEN计算开销大，其实瓶颈往往出在后续环节：因基数误估，优化器选择了Nested Loop而非Hash Join；或把本该走索引的WHERE条件转成全表扫描；又或者低估了GROUP BY后的分组数，导致内存分配不足触发磁盘溢出。
最容易被忽略的是：这种问题在小数据量下完全不暴露，一到生产环境数据膨胀，执行计划就突然劣化——而且不会报错，只默默变慢。
