子查询通常不能替代非等值连接，但MySQL 8.0中可通过预过滤子查询、窗口函数、LATERAL或派生表+索引预聚合实现高效替代。
子查询能替代非等值连接吗？大多数情况下不能，但有例外
MySQL 8.0 的优化器对 JOIN ... ON range_condition（比如 a.id > b.parent_id）天然不友好：无法使用索引下推、常触发全表扫描、执行计划里容易出现 Using where; Using join buffer。这时候有人想用子查询“绕开”——但直接写 (SELECT ... FROM b WHERE b.parent_id < a.id LIMIT 1) 往往更慢，因为对外层每行都执行一次独立子查询（correlated subquery），实际是 N×M 复杂度。
真正可行的替代路径只有两类：
- 子查询用于预过滤（非关联），再与主表做等值连接
- 利用窗口函数或 LATERAL（MySQL 8.0.14+）把非等值逻辑“收编”进可索引结构
用派生表 + 索引预聚合替代 LEFT JOIN ... ON a.x > b.y
典型场景：查每个订单的上一笔订单时间（prev_order_time）。错误写法是：
SELECT a.order_id, a.created_at, (SELECT MAX(b.created_at) FROM orders b WHERE b.created_at < a.created_at) AS prev_time FROM orders a;
这会为每行 a 全表扫 b。正确做法是先用派生表生成有序候选集，再用变量或窗口函数匹配：
SELECT order_id, created_at, LAG(created_at) OVER (ORDER BY created_at) AS prev_time FROM orders;
如果必须用子查询结构（例如兼容旧逻辑），至少要确保子查询不相关：
- 把
b表按关键字段排序后限制范围（如只取最近 1000 条） - 在子查询外层加
WHERE b.created_at >= ? AND b.created_at < ?缩小扫描区间 - 对
b.created_at建联合索引：INDEX(created_at, order_id)
LATERAL 是 MySQL 8.0.14+ 最接近“非等值连接优化”的方案
LATERAL 允许子查询引用左侧表字段，且优化器能将其转为物化临时表 + 索引查找，避免逐行执行。例如找每个用户最近三条登录记录：
SELECT u.id, u.name, l.ip, l.created_at FROM users u LATERAL ( SELECT ip, created_at FROM logins l2 WHERE l2.user_id = u.id ORDER BY created_at DESC LIMIT 3 ) AS l;
关键约束：
-
l2.user_id = u.id必须是等值条件（否则无法利用索引） -
ORDER BY + LIMIT必须有覆盖索引，如INDEX(user_id, created_at) - MySQL 8.0.14 之前不支持
LATERAL，降级只能用应用层分页或存储过程模拟
为什么 EXISTS 子查询有时比 JOIN 快？它根本不是连接
遇到 WHERE EXISTS (SELECT 1 FROM b WHERE b.x > a.y) 这类写法，别误以为是“非等值连接优化”。这是半连接（semi-join），MySQL 8.0 默认启用 semijoin 算法，会自动将子查询转为物化临时表并走哈希查找——前提是子查询里没有 GROUP BY 或聚合函数。
但陷阱明显：
- 如果
b.x > a.y导致子查询返回大量行，物化表本身会变大，反而拖慢 -
EXISTS不返回b的字段，若业务需要b的数据，硬套EXISTS就得额外回表，不如老实用带索引的JOIN - 检查执行计划是否真用了
Materialize：看到Using where; FirstMatch(u)才算生效
非等值连接的本质难点在于无法利用 B+ 树的等值定位能力。所有“子查询优化”都是在绕开这个限制，而不是消除它——索引设计、数据分布、结果集大小，三者稍有变化，最优解就可能完全反转。
