非等值连接慢因索引基本失效，导致范围或全表扫描；需确保字段类型一致、避免函数包装，并用“等值+非等值”顺序建联合索引优化。
非等值连接为什么慢？因为索引基本失效
MySQL 在 JOIN 条件里用 <、>、BETWEEN、!= 这类非等值操作时，无法像 = 那样直接定位索引页，大多退化成范围扫描甚至全表扫描。哪怕两边都有索引，优化器也常放弃使用，尤其当连接字段类型不一致或存在函数包装时。
常见错误现象：EXPLAIN 显示 type=ALL 或 type=range 但 rows 极高；执行时间随数据量非线性增长；Using join buffer 频繁出现。
- 确保连接字段类型完全一致（比如都是
INT UNSIGNED，而非一边SIGNED一边UNSIGNED） - 避免在连接字段上用函数，如
DATE(created_at)或LOWER(name)，这会让索引彻底失效 - 如果必须用范围条件，优先让「驱动表」尽可能小（比如加
WHERE过滤后只剩几百行），再用它去驱动大表
给非等值连接字段建联合索引有用吗？看怎么建
有用，但不是简单地给连接字段单独建索引。关键在于把「等值过滤字段 + 非等值连接字段」按顺序组合进联合索引，且等值字段必须在前。
例如：查询 SELECT * FROM orders o JOIN users u ON o.user_id = u.id AND o.created_at > u.registered_at，其中 o.user_id 是等值，o.created_at 是非等值条件。
- 对
orders表，建INDEX idx_user_created (user_id, created_at)—— 这能让 MySQL 先快速定位到每个user_id下的记录，再在该子集内做created_at > ...范围查找 - 反过来建
(created_at, user_id)效果很差，因为created_at是范围，索引无法有效下推user_id的等值过滤 - 注意：如果连接条件中
user_id实际是NULL或低选择性（比如 80% 值相同），联合索引收益会大幅下降
用 EXISTS 替代非等值 JOIN 真的更快？不一定
很多人听说「用 EXISTS 代替 JOIN 能走索引」就照搬，结果更慢。核心在于：MySQL 对 EXISTS 子查询的优化依赖于能否将外层字段下推到内层，并利用索引快速终止。
示例：查所有有订单晚于注册时间的用户：SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.created_at > u.registered_at)
- 这个写法只有在
orders表上有(user_id, created_at)联合索引时才可能高效；否则仍是全表扫orders - 如果
users表很大且registered_at分布稀疏，EXISTS可能比JOIN更差——因为每次都要为每个用户执行一次子查询 - 测试时务必对比
EXPLAIN FORMAT=JSON中的attached_condition和using_join_buffer是否消失
临时表 + 索引是最后手段，但有时真管用
当驱动表经过 WHERE 过滤后仍较大（几万行以上），又必须和另一个大表做非等值连接，且无法靠联合索引改善时，可以考虑物化中间结果并显式建索引。
比如：先筛选出活跃用户到临时表，再对它建索引，最后和订单表连接。
- 用
CREATE TEMPORARY TABLE tmp_active_users AS SELECT id, registered_at FROM users WHERE last_login > DATE_SUB(NOW(), INTERVAL 30 DAY) - 立刻在临时表上建
INDEX idx_reg (registered_at)—— 注意：临时表默认没索引，必须手动加 - 再执行
SELECT ... FROM orders o JOIN tmp_active_users u ON o.user_id = u.id AND o.created_at > u.registered_at - 缺点：增加磁盘 I/O 和内存开销；并发高时临时表名冲突风险；只适合单次复杂查询，不适合高频接口
真正难处理的是连接条件本身涉及计算或跨类型比较，比如 UNIX_TIMESTAMP(o.created_at) > u.registered_ts —— 这种几乎没法走索引，要么改表结构，要么提前算好冗余字段。
