sql中null判断必须用is null而非= null，类型混用和条件顺序错误会导致逻辑偏差。正确做法是：用is null/is not null判断空值，确认字段类型后统一转换，搜索case替代简单case，优先处理精确匹配，并始终写else避免静默null。
WHEN条件永远不为真，因为NULL参与比较结果是UNKNOWN
当你写 WHEN col = NULL THEN '空'，它永远不会进入这个分支——SQL里 = NULL 永远返回 UNKNOWN，不是 TRUE，也不进 ELSE。这是三值逻辑的刚性规则，和编程语言中 null == null 完全不同。
正确写法只能是：WHEN col IS NULL THEN '空' 或 WHEN col IS NOT NULL THEN '非空'。
- 所有涉及 NULL 的判断都必须用
IS NULL/IS NOT NULL，不能用等号 -
CASE只认TRUE才执行对应分支；UNKNOWN和FALSE效果一样：跳过 - 如果所有
WHEN都没返回TRUE，又没写ELSE，整列就变成NULL——这在聚合或导出时容易静默丢数据
字符串和数字混用，隐式转换让比较结果反直觉
比如字段 score 实际是 VARCHAR 类型，你写 WHEN score >= 90 THEN 'A'，数据库会尝试把字符串转成数字，但一旦遇到 '95abc' 或 ' 87'（带空格），转换可能失败或截断，导致 '95' > 90 返回 FALSE——因为某些库按字典序比，'95' 成立，但 <code>'95' > 90 却可能被当作字符串和数字混合比较而报错或取默认值。
- 先用
SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS确认字段真实类型 - 强制统一类型：数值比较用
CAST(score AS SIGNED)或score + 0（MySQL） - 字符串比较就全程用字符串：
WHEN score IN ('90', '91', '92')，别混着来
条件顺序错乱，宽泛条件挡住了精确匹配
典型错误：WHEN score >= 60 THEN '及格' WHEN score = 100 THEN '满分'。只要分数 ≥ 60，第一个分支就命中，score = 100 根本没机会被检查。
- 把范围更窄、优先级更高的条件往前放：满分 → 优秀 → 良好 → 及格 → 不及格
- 边界值要显式覆盖：比如
score = 100、score BETWEEN 90 AND 99、score （防异常负分） - 用
SELECT先验证逻辑：SELECT score, CASE ... END AS level FROM t LIMIT 10，人工核对几条关键值
误用简单CASE写法，却在里面塞布尔表达式
写成 CASE score WHEN >= 90 THEN 'A' 是语法错误——CASE score WHEN ... 是简单 CASE，只支持 WHEN 常量，不接受 >=、IN、函数等任意表达式。
真正该用的是搜索 CASE：CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ...
- 简单 CASE 仅用于等值映射，如
CASE status WHEN 1 THEN '启用' WHEN 0 THEN '停用' - 只要条件含运算符、函数、NULL 判断、范围比较，一律用搜索 CASE
- 漏写
END会直接报ERROR 1064；漏写ELSE不报错，但容易让意外值变NULL
