能，但需确保字段存在、类型兼容且数据库支持；否则易报错或返回空结果，且NULL参与运算会导致连接失败。
ON子句里能直接写
吗？
能，但必须确保参与计算的字段在各自表中真实存在、类型兼容，且数据库支持该语法（主流如 PostgreSQL、MySQL 8.0+、SQL Server 都支持）。关键不是“能不能写”，而是“写了之后会不会出错或查不到数据”。
常见错误现象：
（别名未生效）、
（比如
是字符串）、或结果全为
（某字段含空值且未处理）。
子句中的表达式在连接时实时计算，不走索引，性能敏感场景要谨慎
别名（如
,
）必须在
中明确定义，不能在
里临时起别名
如果任一操作数为
，整个表达式结果为
，会导致连接失败（
下该行被丢弃）
如何安全地在 ON 中做跨表价格折算匹配
典型场景：订单表
要和促销规则表
关联，条件是“订单实付金额落在促销门槛区间内”，而门槛是动态计算的（比如
）。
正确写法示例：
注意点：
用
处理可能为
的乘数，避免整行失效
不要在
里调用不可下推的函数（如
、
），某些数据库优化器无法利用索引
MySQL 中若
是字符串类型，需显式转成数字：
为什么 WHERE 里算好再 JOIN 不如 ON 里直算
不是“不如”，而是语义不同。把计算挪到
是先连接后过滤，而
是定义连接逻辑本身。
例如：
→ 只有满足该等式的行才进入连接结果
→ 先按
连接，再筛，可能产生大量中间行
尤其对
，放在
和
差异巨大：
会把右表为
的行也过滤掉，实际变成
。
PostgreSQL vs MySQL 在 ON 表达式里的坑
两者都支持数学表达式，但细节差异容易踩：
PostgreSQL 对类型更严格：
没问题，但
直接报错；MySQL 可能隐式转成数字（如
→
），也可能转成
（如
）
MySQL 5.7 默认开启
时，
得
；关了可能得
，行为不一致
PostgreSQL 支持在
里用子查询（只要返回单值），MySQL 不支持
跨数据库移植时，优先用显式类型转换和空值防御，别依赖隐式行为。
最常被忽略的是：ON 里的表达式不会被查询计划器重写或下推到物化视图/分区裁剪逻辑里——这意味着即使你写了
在 ON 里，也未必触发分区跳过。真要靠条件裁剪，得放到 JOIN 之外或分区键上。
a.price * a.tax_rateColumn 'a.tax_rate' not foundInvalid operand types for *tax_rateNULLONabFROMONNULLNULLINNER JOINorderspromotionsbase_amount * discount_factorSELECT o.order_id, p.name
FROM orders o
INNER JOIN promotions p
ON o.total_amount >= p.min_base * COALESCE(p.factor, 1.0)
AND o.total_amount < p.max_base * COALESCE(p.factor, 1.0);COALESCENULLONUPPER()CONCAT()p.factorCAST(p.factor AS DECIMAL(5,2))WHEREONON o.amount = p.threshold * 1.1ON o.id = p.order_id WHERE o.amount = p.threshold * 1.1idLEFT JOINONWHEREWHERENULLINNER JOININT * NUMERICTEXT * INT'123'1230'abc'STRICT_TRANS_TABLESNULL * 100NULL0ONo.created_at > '2024-01-01'