SQL表达式严格按操作符优先级求值，非简单左到右；NULL参与运算结果为NULL，遵循三值逻辑；隐式转换不可控且跨库差异大；函数执行时机受优化器影响；类型、NULL、优化器与事务共同决定表达式行为。
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，而不是报错或跳过。这不是“空值参与计算失败”，而是 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。再如把字符串 '2025-10-01' 和日期列比较，MySQL 可能自动转成日期，SQL Server 可能抛异常。
CAST(col AS INTEGER) 或 CONVERT(INTEGER, col)，语义清晰且跨库可读WHERE phone_number = 13800138000，若 phone_number 是 VARCHAR，MySQL 可能放弃索引做全表扫描）'2025-10-01'）并配合 DATE() 或 TO_DATE() 显式解析，别信 col > '2025-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()，而非逐行先算长度。
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 被跳过、因隐式转换导致索引失效，甚至在不同隔离级别下返回不同结果。