SQL处理复杂业务规则的核心是分层判断而非堆砌CASE，需先理清规则优先级（如先筛终态“已关闭”），再用CTE归一化中间逻辑，显式处理NULL和边界值，并通过统计与抽样验证覆盖度。
SQL里处理复杂业务规则，核心不是堆砌CASE，而是把业务逻辑拆解清楚再映射到条件分支。关键在分层判断、避免冗余、兼顾可读与可维护。
先理清业务规则层级，再写CASE
比如一个电商订单状态计算规则：
- 已付款且发货超48小时 → “已完成”
- 已付款但未发货 → “待发货”
- 未付款但有库存锁定 → “预占中”
- 未付款且无锁定 → “草稿”
- 已取消或支付超时 → “已关闭”
直接平铺5个WHEN容易漏判或顺序错。应按优先级分组：先筛“已关闭”（终态），再处理“进行中”（待发货/已完成/预占中），最后兜底。状态字段本身也要参与判断，不能只依赖时间戳。
嵌套CASE要控制深度，用子查询或CTE提前归一化
当判断依赖多个字段组合（如：地区+会员等级+促销类型），硬写多层CASE可读性差。建议：
- 用WITH定义中间逻辑表，把“是否满足满减门槛”“是否VIP免运费”等布尔结果先算出来
- 主CASE只基于这些语义明确的字段分支，例如：WHEN is_vip AND meets_freight_free THEN '免运费'
- 避免CASE WHEN ... THEN (CASE WHEN ...) END这种三层以上嵌套
注意NULL和边界值，别让规则“意外跳过”
CASE是顺序匹配，第一个满足的WHEN就返回，其余忽略。常见坑：
- 没写ELSE，遇到NULL或未覆盖情况返回NULL，可能引发前端空状态
- 时间比较用BETWEEN却忽略时区或毫秒精度，导致“刚发货”被误判为“已完成”
- 金额比较用= 0判断“未付款”，但实际可能是NULL（支付系统未回传）
稳妥做法：显式处理NULL，例如WHEN payment_status IS NULL OR payment_status = 'pending' THEN '待付款'。
上线前用真实数据反向验证规则覆盖度
写完CASE别急着提交。执行一句统计：
SELECT status_label, COUNT(*) FROM (你的主查询) GROUP BY status_label;
检查是否有意料之外的分组（比如出现NULL或空字符串），再抽样几条“边缘case”——比如刚好卡在48小时临界点的订单、VIP用户叠加优惠券的场景——人工核对输出是否符合业务预期。
