输入值为NULL时多CASE语句失效，求SQL查询修复与优化方案

嘿，我来帮你搞定这个SQL的问题！咱们先拆解下你遇到的问题，再给出更简洁可靠的写法：

原CASE语句的潜在问题 #

你提到第三、第四个WHEN分支无法正常工作，大概率是这两个原因：

• 参数类型不匹配：如果@start_date/@end_date是字符串类型，而u.created_at是timestamp/datetime类型，直接比较可能会因为格式不兼容导致判断失效。建议确保参数和字段类型一致，或者用STR_TO_DATE()把字符串转成对应时间类型（比如STR_TO_DATE(@start_date, '%Y-%m-%d %H:%i:%s')，根据你的实际时间格式调整）。
• 冗余的布尔判断：原CASE最后多了= true的写法，其实CASE本身返回的就是布尔值，这步完全没必要，虽然不会直接导致分支失效，但会增加代码冗余。

简化后的SQL写法 #

你的需求完全可以不用CASE语句，直接用布尔条件组合实现，代码更简洁可读性更强，还能避免CASE分支匹配可能带来的问题：

SET @start_date = 'your_start_timestamp'; 
SET @end_date = 'your_end_timestamp'; 

SELECT DISTINCT u.user_id 
FROM user_plan u 
JOIN user_feature uf ON uf.user_plan_id = u.id 
WHERE uf.status IN ('PENDING_ACTIVE', 'PENDING_INACTIVE')
  -- 核心逻辑：参数为空时自动忽略对应限制，不为空时校验时间范围
  AND (@start_date IS NULL OR u.created_at >= @start_date)
  AND (@end_date IS NULL OR u.created_at <= @end_date);

逻辑说明 #

这个写法和你原来的CASE逻辑完全等价，但更清晰：

• 当@start_date为空时，@start_date IS NULL为真，第一个条件自动成立，相当于忽略start_date的限制；
• 当@start_date不为空时，要求u.created_at必须晚于等于这个起始时间；
• 同理，@end_date为空时忽略结束时间限制，不为空时要求u.created_at早于等于这个结束时间；
• 两个参数都为空时，两个条件都成立，返回所有符合status的记录；
• 两个参数都不为空时，自动校验u.created_at是否在时间区间内。

额外提醒 #

如果你的参数是纯日期字符串（比如'2024-05-01'），而u.created_at是带时分秒的时间戳，可以用DATE(u.created_at)来匹配，或者把参数补全为带时间的格式，避免因时间精度导致的判断误差。

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