不等号JOIN触发全表扫描：用<、>、<>或!=做JOIN条件时，数据库无法使用索引定位匹配行，只能对被驱动表执行全表扫描，导致IO爆炸性增长。
不等号JOIN触发全表扫描 × 全表扫描
用 <、>、<> 或 != 做 JOIN 条件时，数据库几乎无法使用索引定位匹配行，只能对被驱动表执行全表扫描——而这个动作要为驱动表的每一行都重复一次。10 万行驱动表 × 每次扫 50 万行被驱动表 = 500 亿行 IO 访问，磁盘直接打满。
常见错误现象：
- EXPLAIN 中被驱动表的
type显示ALL，rows值等于整张表行数 -
Extra出现Using where; Using join buffer (Block Nested Loop) - 查询过程中
iostat -x 1显示%util持续 100%，await超过 100ms
为什么等值JOIN能走索引，而不等号不能
等值条件（如 t1.user_id = t2.owner_id）可借助 B+ 树索引快速定位单个值或连续范围；但不等号（如 t1.created_at < t2.updated_at）无法确定起始点和边界，优化器只能放弃索引查找，退化为逐行比对。
关键细节：
- 即使两列都有独立索引，
<条件也无法下推到索引遍历中——B+ 树不支持“找所有小于某值的键”的高效跳转 - 复合索引（如
(a, b)）在a < ? AND b > ?场景下可能部分生效，但仅限最左前缀匹配，且仍需回表过滤 - PostgreSQL 的
BRIN索引对时间范围类不等号有一定加速作用，但仅适用于严格递增写入场景，且不适用于高并发更新表
LEFT JOIN + 不等号会让NULL行也参与全量扫描
LEFT JOIN 本意是保留左表全部记录，但一旦 ON 中含不等号（如 ON t1.id < t2.ref_id），右表每行都要与左表当前行比对——包括右表为 NULL 的情况。此时优化器无法跳过空值判断逻辑，导致额外开销。
更隐蔽的问题：
- WHERE 中再加非空判断（如
WHERE t2.id IS NOT NULL）不会提前剪枝，因为 LEFT JOIN 已强制加载右表全部数据 - 若右表有大字段（如
TEXT），不等号会触发 LOB 全量加载，每行拉几 MB，缓冲池瞬间溢出 - MySQL 8.0+ 的哈希连接（Hash Join）不支持不等号条件，强制回落到块嵌套循环（BNL），内存不足时写磁盘临时表，IO 雪上加霜
替代方案：用范围预聚合或物化中间结果
真需要“小于关系”语义（如查每个用户最新一条订单之前的所有日志），不要硬写不等号 JOIN，而是分步收敛数据边界。
可行做法：
- 先用子查询或 CTE 找出关键阈值：
SELECT user_id, MAX(order_time) AS max_time FROM orders GROUP BY user_id - 再用等值 JOIN 关联日志表：
JOIN logs l ON l.user_id = u.user_id AND l.log_time < u.max_time - 确保
logs(user_id, log_time)有复合索引，让第二步变成索引范围扫描而非全表 - 若阈值计算开销大，可建物化视图（PostgreSQL）或冗余字段（MySQL）缓存结果
真正危险的不是“想表达大小关系”，而是把这种关系直接塞进 JOIN 条件里——它绕过了所有索引机制，也骗过了优化器的成本估算。只要看到 ON 里出现不等号，就该默认这句 SQL 已经站在 IO 崩溃的边缘。
