where 子句中不能直接使用 if 或 case 作为控制语句，只能用 case 表达式返回布尔值参与比较；正确写法是布尔逻辑组合或 case when…then…else…end 配合数据库布尔支持。
WHERE 子句里不能直接写 IF 或 CASE 表达式？
不是不能，而是得用 CASE 作为表达式参与比较，而不是当控制语句用。SQL 没有“执行分支”的概念，只有“计算出一个值再比对”。比如想查“状态为 1 且金额 > 100，或状态为 2 且金额 > 50”的记录，别写 IF status = 1 THEN amount > 100 ELSE amount > 50 —— 这语法根本报错。
正确做法是把逻辑拆成布尔组合：
WHERE (status = 1 AND amount > 100) OR (status = 2 AND amount > 50)- 或者用
CASE构造统一判断项：WHERE CASE WHEN status = 1 THEN amount > 100 WHEN status = 2 THEN amount > 50 ELSE FALSE END（注意：部分数据库如 PostgreSQL 支持布尔值直接参与 WHERE，MySQL 则需转成= TRUE） - 嵌套太深时，
CASE易读性反而下降，优先选括号分组的布尔逻辑
想在 SELECT 中动态返回不同字段值，该用 CASE 还是 COALESCE？
CASE 是通用解法，COALESCE 只解决“取第一个非 NULL”的线性 fallback 场景。比如要根据 type 字段返回不同计算结果：CASE type WHEN 'A' THEN price * 0.9 WHEN 'B' THEN price * 1.1 ELSE price END —— 这没法用 COALESCE 替代。
常见误用：
- 用
COALESCE(a, b, c)代替CASE WHEN a IS NOT NULL THEN a WHEN b IS NOT NULL THEN b ELSE c END：表面等价，但语义不同 ——COALESCE不关心字段含义，只看 NULL；而业务逻辑常依赖具体条件（比如type = 'discount'才用折扣价） -
CASE分支中混用数据类型（如有的返回INT，有的返回VARCHAR），会导致隐式转换失败或截断，务必显式CAST
存储过程中写 IF/ELSE 报错：’IF is not valid at this position’？
这是典型语法隔离问题：标准 SQL（如用于查询的 SQL）不支持过程式控制流；只有特定数据库的存储过程语言才支持，而且语法差异极大。
关键区分点：
- MySQL 存储过程用
IF …… THEN …… ELSE …… END IF;，但必须写在CREATE PROCEDURE内部，不能在普通查询窗口执行 - PostgreSQL 用
plpgsql语法：IF condition THEN …… ELSE …… END IF;，同样只能出现在函数体中 - SQL Server 的
IF …… BEGIN …… END仅在批处理或存储过程中有效，单独执行会提示“Incorrect syntax near ‘IF’” - 想在普通查询里模拟分支？老实用
CASE表达式，别硬塞过程语句
复杂嵌套 CASE 导致性能骤降，怎么定位和优化？
不是 CASE 本身慢，而是它常被写在 WHERE 或 JOIN 条件里，导致索引失效或全表扫描。比如：WHERE CASE WHEN category = 'A' THEN created_at > '2023-01-01' ELSE created_at > '2022-01-01' END —— 数据库很难对这种动态条件做索引下推。
实操建议：
- 先看执行计划：重点检查
type是否为ALL（全表扫描），key列是否为空 - 把 CASE 拆成 UNION ALL（前提是分支互斥）：
(SELECT …… WHERE category = 'A' AND created_at > '2023-01-01') UNION ALL (SELECT …… WHERE category != 'A' AND created_at > '2022-01-01')，让每个子查询能走索引 - 避免在 JOIN ON 里用 CASE 做关联逻辑，宁可拆成多个 LEFT JOIN + COALESCE 组合
最常被忽略的一点：CASE 表达式里的子查询如果没加 LIMIT 或没走索引，整个外层查询都会被拖垮——别只盯着 CASE，先确保它里面调的每一部分都快。
