非等值join需用范围条件（如on a.amount >= b.min_amount and a.amount
非等值JOIN的语法写法与常见错误
SQL里不能用 ON a.id = b.id 这种等值条件来匹配价格区间，必须改用 ON a.amount >= b.min_amount AND a.amount 这类范围判断。但很多人一写就报错，典型原因是：MySQL 5.7 默认禁止非等值条件用于 <code>JOIN（报错 ERROR 1054: Unknown column 或优化器拒绝执行），而 PostgreSQL 和 SQL Server 则天然支持；MySQL 8.0+ 虽支持，但若没加索引，性能会断崖式下跌。
实操建议：
- 确认数据库版本是否支持——MySQL 用户优先查
SELECT VERSION() - 避免在
ON子句里混用AND和OR，比如ON a.x > b.low OR a.x 会导致结果不可控 - 别把区间表写成
LEFT JOIN后再用WHERE过滤，否则会意外转成内连接（例如LEFT JOIN ... ON ... WHERE b.price IS NOT NULL）
阶梯定价表的设计要点
区间匹配成败一半取决于定价表结构。最常踩的坑是边界重叠或留空：比如两条记录分别是 min=0, max=100 和 min=100, max=200，那金额正好等于 100 时可能被两条同时匹配（取决于是否用 还是 <code>），也可能一条都不中（如果用了 <code> 但下一段从 101 开始）。
推荐设计方式：
- 统一用左闭右开区间：
min_amount（含）、max_amount（不含），例如(0, 100), [100, 200), [200, +∞) - 补全兜底行：
min_amount = 200, max_amount = NULL或设为极大值如999999999，并确保该行max_amount字段允许为NULL或有明确上界 - 给
min_amount和max_amount同时建复合索引：INDEX idx_range (min_amount, max_amount)，否则 MySQL 8.0+ 也可能全表扫描定价表
实际计算示例：订单金额匹配阶梯单价
假设有订单表 orders（含 order_id, amount），和阶梯价目表 price_tiers（含 tier_id, min_amount, max_amount, unit_price）。要算每笔订单的应付金额（amount * unit_price），直接写：
SELECT o.order_id, o.amount, p.unit_price, o.amount * p.unit_price AS total_price FROM orders o JOIN price_tiers p ON o.amount >= p.min_amount AND (o.amount <p>注意括号位置——<code>OR p.max_amount IS NULL</code> 必须和 <code>o.amount 一起放在括号内，否则逻辑优先级出错。另外，如果定价表里存在 <code>max_amount = 0</code> 这种异常数据，会导致所有正数金额都跳过该行，务必提前清洗。</code></p><h3>性能敏感点：为什么查询越来越慢</h3><p>非等值 JOIN 无法利用传统哈希连接或索引查找的加速路径，多数数据库会退化为嵌套循环（Nested Loop），当订单表有 10 万行、定价表有 50 行时，最坏要做 500 万次比较。这不是写法错，而是模型限制。</p><p>可缓解的方式：</p>
- 对
orders.amount加索引，让数据库能快速定位“可能命中哪些 tier”的粗粒度范围（部分引擎如 PostgreSQL 会用索引辅助范围 JOIN） - 把定价表缓存到应用层，用二分查找代替 SQL 区间匹配（适合 tier 数量固定且更新不频繁的场景）
- 避免在
ON条件里调用函数，例如ON o.amount >= FLOOR(p.min_amount)会让索引失效
真正棘手的是跨时区、多币种、带有效期的复合阶梯——这时单靠 SQL 的非等值 JOIN 很难兼顾可读性与性能，得拆成预计算宽表或引入规则引擎。
