MySQL简单CASE语句执行异常，请求协助排查问题原因

我来帮你拆解这个奇怪的问题——你遇到的情况大概率和数据类型隐式转换或者CASE分支的逻辑细节有关，咱们一步步理清楚：

首先明确：MySQL里smallint(4)的存储范围是-32768到32767，1050完全在这个区间内，所以肯定不是值超出字段类型范围的问题。接下来给你列几个最可能的原因和对应的排查方案：

1. 目标数据不存在，或被NULL干扰 #

先确认你的表中真的存在avg_weight = 1050的记录：

SELECT COUNT(*) FROM your_table WHERE avg_weight = 1050;

如果返回0，那CASE语句自然不会返回对应分支的结果——而改成0的时候能返回数据，大概率是表中存在avg_weight = 0的记录。另外如果表中有大量NULL值，且CASE语句没写ELSE分支，不符合条件的行都会返回NULL，看起来就像是“无法正常工作”。

2. 隐式转换导致判断失效 #

虽然字段定义是smallint，但如果你的CASE语句里的判断值是字符串形式（比如不小心加了引号'1050'），或者分支返回的类型不统一，可能会触发隐式转换，导致判断逻辑异常。比如：

-- 错误示例：判断值用了字符串，可能触发转换问题
CASE WHEN avg_weight = '1050' THEN 'Heavy' ELSE avg_weight END AS wt_type

解决方法是显式统一类型：

-- 显式把判断值转成smallint
CASE WHEN avg_weight = CAST(1050 AS SMALLINT) THEN 'Heavy' ELSE 'Light' END AS wt_type

3. 字段实际存储的是异常值 #

有时候字段定义是smallint，但实际存储的数据可能有隐藏的格式问题（比如导入时带了空格、不可见字符）。你可以用HEX函数查看实际存储的字节：

SELECT avg_weight, HEX(avg_weight) FROM your_table WHERE avg_weight LIKE '%1050%';

正常smallint类型的1050，HEX值应该是041A（1050转十六进制为0x41A），如果返回结果不符，说明数据有异常，需要清理。

最后建议 #

如果以上排查都没问题，把你的完整CASE语句贴出来，我可以帮你再细化分析——毕竟有时候一个不起眼的符号（比如把=写成>=）也会导致逻辑不符合预期。

内容的提问来源于stack exchange，提问作者cstewart28