SQL 中表达式是如何计算的？

sql表达式严格按操作符优先级求值，非简单左到右；NULL参与运算结果为NULL，遵循三值逻辑；隐式转换不可控且跨库差异大；函数执行时机受优化器影响；类型、NULL、优化器与事务共同决定表达式行为。

SQL 表达式按标准优先级从左到右求值

SQL 表达式不是简单地从左到右扫一遍就完事，而是严格遵循操作符优先级（如 * 和 / 高于 + 和 -），相同优先级时才左结合。括号会强制改变求值顺序，且优先级规则在所有主流数据库（postgresql、mysql、SQL Server、sqlite）中基本一致。

常见误判是以为 WHERE a + b * c > 10 先算 a + b，实际先算 b * c。不加括号容易写出逻辑错误的条件。

• 数值运算优先级：括号 > ^（幂，部分数据库支持）> *, /, % > +, -
• 比较运算符（=, , > 等）优先级低于算术运算，但高于逻辑运算
• 逻辑运算符优先级： NOT > AND > OR —— 这点尤其容易被忽略，WHERE a = 1 OR b = 2 AND c = 3 等价于 WHERE a = 1 OR (b = 2 AND c = 3)，不是 (a = 1 OR b = 2) AND c = 3

NULL 在表达式中会传染性传播

只要表达式中任意操作数为 NULL，绝大多数内置运算（+, -, *, /, 比较运算等）结果就是 NULL，而不是报错或跳过。这不是“空值参与计算失败”，而是 SQL 标准定义的三值逻辑行为。

例如：5 + NULL 返回 NULL；NULL = NULL 不返回 TRUE，而是 UNKNOWN（在 WHERE 中等效于 FALSE）；COALESCE(col, 0) * 10 是安全绕过方式。

• NULL 和任何字符串拼接（如 col || NULL）结果仍是 NULL（PostgreSQL/oracle），但 MySQL 默认把 NULL 当空字符串处理（受 sql_mode 影响）
• CASE 表达式中，WHEN 子句的比较也遵循三值逻辑，WHEN col = NULL 永远不匹配，必须写成 WHEN col IS NULL
• 聚合函数如 SUM()、AVG() 会自动忽略 NULL 值，但 count(*) 和 COUNT(col) 行为不同：前者计所有行，后者只计 col 非 NULL 的行

类型隐式转换发生在表达式求值前

当操作符两侧数据类型不同时，数据库会按自身规则尝试隐式转换。这个过程不透明、不可控，且各数据库差异极大——这是线上出错和性能抖动的高发区。

比如 MySQL 中 '123abc' + 45 会截取前缀转成 123 + 45 = 168；而 PostgreSQL 直接报错 Error: operator does not exist: text + Integer。再如把字符串 '2023-10-01' 和日期列比较，MySQL 可能自动转成日期，SQL Server 可能抛异常。

• 避免依赖隐式转换：显式用 CAST(col AS INTEGER) 或 CONVERT(INTEGER, col)，语义清晰且跨库可读
• 字符串与数字混用时，索引很可能失效（如 WHERE phone_number = 13800138000，若 phone_number 是 VARCHAR，MySQL 可能放弃索引做全表扫描）
• 日期字符串比较务必用标准格式（'2023-10-01'）并配合 date() 或 TO_DATE() 显式解析，别信 col > '2023-10' 这种模糊写法

函数调用时机取决于上下文和优化器

SQL 是声明式语言，select func(x) FROM t 中的 func() 并不保证每行都执行一次——如果优化器判定该函数是确定性的（DETERMINISTIC）且参数不变，可能提前计算、复用结果；反之，像 NOW()、RANDOM()、USER() 这类非确定性函数，每次被引用都会重新求值（甚至同一行内多次出现也会多次调用）。

更隐蔽的是，WHERE 子句中的函数可能被下推或上拉，执行顺序未必和书写顺序一致。例如 WHERE LENGTH(name) > 5 AND name LIKE 'A%'，优化器可能先走索引查 name LIKE 'A%'，再对结果集算 Length()，而非逐行先算长度。

• 自定义函数（UDF）默认被视为非确定性，除非显式声明 DETERMINISTIC，这会影响是否能用于函数索引（如 MySQL 的函数索引、PostgreSQL 的表达式索引）
• ORDER BY 中的表达式会在排序前完整计算一遍，但不会缓存；若表达式复杂（如嵌套 jsON 解析），建议先用 WITH 子句物化中间结果
• 窗口函数（如 ROW_NUMBER() OVER (ORDER BY x)）的求值阶段独立于 WHERE 和 GROUP BY，它在逻辑上发生在 ORDER BY 之前、SELECT 投影之后

真正难的不是记住优先级表，而是意识到：表达式求值不是孤立的数学运算，它穿插在类型系统、NULL 语义、优化器决策和事务快照之间。一个看似简单的 WHERE a / b > 1，可能因 b = 0 报错、因 b 为 NULL 被跳过、因隐式转换导致索引失效，甚至在不同隔离级别下返回不同结果。