SQL不将短路作为语言特性，因其是声明式语言，逻辑运算符面向集合操作而非过程求值，标准未规定求值顺序，主流数据库不保证短路；需确定性顺序时应使用CASE WHEN。
SQL 标准本身不定义“布尔短路”这一行为，因为 SQL 的逻辑表达式（如 AND、OR）在语义上被设计为**集合操作**而非过程式求值，数据库引擎是否实际执行短路取决于具体实现，且多数主流系统（如 PostgreSQL、SQL Server、Oracle、MySQL）在标准查询中不保证也不依赖短路求值。
为什么 SQL 不把短路作为语言特性
SQL 是声明式语言，关注“要什么”，而非“怎么算”。逻辑运算符作用于整个结果集，优化器可能重排计算顺序、并行处理或提前剪枝，但这些都属于执行层优化，不暴露给用户语义。标准 SQL 未规定表达式必须从左到右、遇假即停，因此不能像编程语言（如 Java、Python）那样依赖 AND 左侧为 false 就跳过右侧。
实际执行中短路常不可靠
- Oracle 和 SQL Server 在 WHERE 子句中可能因统计信息或执行计划选择而跳过部分谓词，但这不是语法保障，而是优化器行为
- PostgreSQL 明确文档指出：“逻辑运算符不保证求值顺序”，尤其在涉及函数调用时（如
func() AND col = 1），func()可能被提前执行甚至多次执行 - MySQL 8.0+ 对简单常量表达式可能优化掉冗余判断，但含子查询、UDF 或窗口函数时基本不短路
替代方案：用 CASE 显式控制求值顺序
若需确定性执行顺序（例如避免空指针、高代价函数或副作用），应使用 CASE WHEN：
✓ 安全写法：CASE WHEN col IS NOT NULL THEN expensive_function(col) ELSE NULL END
这强制先判断条件，再决定是否调用函数，语义清晰、跨数据库可移植。
特别注意 NULL 与三值逻辑的影响
SQL 使用三值逻辑（TRUE/FALSE/UNKNOWN），NULL AND TRUE 结果是 UNKNOWN，不是 FALSE；NULL OR FALSE 也是 UNKNOWN。这种逻辑下，“短路”概念本身已模糊——比如 FALSE AND unknown 可直接得 FALSE，但标准不强制引擎利用这点，因为 UNKNOWN 可能来自动态数据，优化器难以静态推断。
