CASE WHEN报错因各THEN/ELSE分支类型不一致，数据库编译时需推断唯一返回类型；Oracle最严格，SQL Server按优先级转换，MySQL隐式转但易出错；修复须显式CAST或TO_CHAR统一类型。
为什么CASE WHEN的THEN分支类型不一致就报错
CASE WHEN不是函数，而是SQL标准定义的**标量表达式**，整个表达式必须返回单一确定的数据类型。数据库在编译阶段就要推断出这个类型——它取所有THEN和ELSE分支中“最高优先级”的类型作为最终类型。一旦分支间类型冲突（比如一个返回'字符串'，另一个返回123），数据库无法统一推断，就直接报错，如Oracle的ORA-00932、SQL Server的类型转换失败提示。
不同数据库对类型不一致的处理差异
各数据库对隐式转换的容忍度不同，但底线一致：不能让一个CASE表达式动态返回多种类型。
- Oracle最严格：不允许
CHAR和NUMBER混用，也不允许DATE和VARCHAR2混用，必须显式转成同一类型（常用TO_CHAR()或TO_NUMBER()） - SQL Server按数据类型优先级决定结果类型，
int优先级高于varchar，所以CASE WHEN x=1 THEN 'a' ELSE 2 END会尝试把'a'转成int，必然失败 - MySQL相对宽松，会做隐式转换（比如把数字转成字符串），但可能截断、丢失精度，或在严格模式下直接报错
怎么快速判断和修复类型不一致问题
别靠猜，用最直白的方式验证：把每个THEN和ELSE后面的值单独拿出来执行，看它们各自的类型是什么。
- 在Oracle里用
SELECT DUMP('x') FROM dual看内部表示；在SQL Server里用SELECT SQL_VARIANT_PROPERTY(123, 'BaseType') - 统一手段是显式转换：所有分支都套一层
CAST(... AS VARCHAR)或TO_CHAR(...)，尤其当你要混用字符串、数字、日期时 - 避免用
NULL裸写在ELSE里——它的类型是未知的，可能被推断为INT或VARCHAR，引发意外冲突；改用CAST(NULL AS VARCHAR)明确类型 - 如果某分支是子查询，必须确保它只返回单值且类型可预测，否则先用
(SELECT TOP 1 ...)或COALESCE((SELECT ...), 'default')兜底
CASE WHEN里嵌日期或空格时最容易翻车
这类场景特别隐蔽：你以为' '（空格）和TO_DATE(...)都是“值”，但数据库眼里一个是VARCHAR2，一个是DATE。错误示例：CASE WHEN col = '' THEN ' ' ELSE TO_DATE(col, 'YYYYMMDD') END。修复不是加个TO_CHAR()就完事——还要确认格式是否满足业务需求，比如要不要补DEFAULT ' ' ON CONVERSION ERROR防解析失败。
真正麻烦的是那些看似无害的空值分支、隐式转换链、以及跨数据库迁移时的类型假设。类型一致性不是“能跑就行”，而是SQL执行计划稳定性和结果可预期性的基础。
