不等值JOIN无法用常规索引加速，因其破坏单点查找能力，优化器无法利用B+树索引快速定位，预估返回行数过多时甚至弃用索引，最终退化为嵌套循环暴力匹配，导致CPU飙升。
不等值 JOIN（如 、<code>、<code>BETWEEN、!=）本身无法走索引驱动的 Nested Loop，又不能被优化器转成 Hash Join 或 Merge Join，最终被迫退化为嵌套循环暴力匹配——这是 CPU 打满的直接原因。
为什么不等值 JOIN 无法用常规索引加速
数据库对等值 JOIN（=）能利用索引快速定位匹配行，但不等值条件破坏了“单点查找”能力：
ON a.id 没法用 <code>b.ref_id上的 B+ 树索引做一次 Seek 就拿到结果，必须扫描所有ref_id > a.id的行- 即使
b.ref_id有索引，优化器也常放弃使用——因为预估返回行数太多，走索引反而比全表扫描更慢（尤其当a.id值很小时） - MySQL 8.0+ 和 PostgreSQL 都不支持在不等值 JOIN 上做 Index Nested Loop，只能回退到 Block Nested Loop 或纯内存嵌套循环
执行计划里一眼识别不等值 JOIN 的 CPU 风险
运行 EXPLAIN FORMAT=TREE（MySQL）或 EXPLAIN (ANALYZE)（PostgreSQL），重点看这三点：
- 出现
Nested Loop节点，且内表访问类型是ALL（MySQL）或Seq Scan（PostgreSQL） - 外层表
rows预估值不大（比如几百），但实际执行时内层被扫描了几十万次（Actual Loops × Rows极高） - Extra 字段含
Using join buffer（MySQL）或Buffers: shared read=数值异常大（PostgreSQL）
比加索引更有效的三种绕过方式
给不等值字段加索引基本无效；真正能压低 CPU 的是改写逻辑或控制数据规模：
- 把不等值 JOIN 拆成两步：先用等值条件拉出候选集（如
JOIN ... ON a.type = b.type），再在应用层或临时表里做过滤 - 用
RANGE JOIN替代（仅 PostgreSQL 16+ 支持）：JOIN LATERAL (SELECT * FROM b WHERE b.ref_id > a.id LIMIT 10)，避免全量匹配 - 加
LIMIT+ 分页驱动：如果业务只要前 N 条，强制让优化器走Index Scan + Limit，例如SELECT ... FROM a JOIN b ON a.id
不等值 JOIN 的本质问题是“没有高效的数据跳转路径”，不是调参或加硬件能解决的。最容易被忽略的是：开发阶段看到 EXPLAIN 显示“用了索引”就以为安全，其实只要 type 是 range 且 rows 过万，配合不等值条件，CPU 就已在边缘。
