Index Join在点查询场景下比Hash Join更高效，因其利用B+树确定性路径单次定位、无需构建哈希表、支持覆盖索引与范围查询，且缓存友好；而Hash Join需全表扫描建表、不支持排序/范围、内存与CPU开销大。
Index Join（基于索引的嵌套循环连接）在点查询（如 WHERE id = 123 或 ON t1.a = t2.a AND t2.a = 42）场景下比 Hash Join 更高效，根本原因不是“索引更快”，而是 B+ 树天然适配单值定位，且无需构建/探测哈希表的额外开销。
点查询时 Index Join 直接走 B+ 树查找路径
B+ 树对等值查询（=）的搜索是确定性路径：从根节点逐层比较键值，最多树高次磁盘 I/O 就能定位到叶子页。例如 t2.a = 42，若 a 有索引，MySQL 可直接跳转到含该键的叶子节点，读 1 行 —— 不需要扫描、不依赖内存大小、不触发临时结构。
Hash Join 则必须先扫描整个被驱动表（或其满足条件的子集）构建哈希表，再对驱动表每行做哈希探测。即使只查一个值，它仍要为整张表建哈希桶，浪费 CPU 和内存。
常见错误现象：EXPLAIN 显示 type=ALL 或 type=index 却没走 ref，说明关联字段没索引或用了函数（如 ON UPPER(t1.name) = UPPER(t2.name)），强制退化成全表扫描式 Join。
Index Join 天然支持范围 + 排序 + 覆盖，Hash Join 完全不支持
点查询常伴随后续需求：比如查出 t2.a = 42 的所有行后，还要按 b 排序，或只取 a, b 两列。B+ 树索引本身有序，且可定义为联合索引 (a, b)，此时：
- 查
a = 42是点查询，直接定位到第一个匹配项 - 后续相同
a值的行在叶子页中物理连续，顺序读即可 - 若查询字段全在索引中（
SELECT a, b），连主表都不用回，即覆盖索引
Hash Join 输出无序，不支持范围条件（>、BETWEEN），也不能利用索引字段顺序减少 I/O。一旦查询变成 t2.a > 40 AND t2.a < 45，Hash Join 彻底失效，而 Index Join 仍能用索引快速定位起止位置。
小结果集驱动 + 索引下推让 Index Join 实际更轻量
当驱动表结果很小（如 t1 只返回 5 行），Index Join 实际执行就是 5 次 B+ 树单点查找。每次查找都可利用 MySQL 5.6+ 的索引下推（ICP）优化：如果被驱动表索引是 (a, b)，而查询是 ON t1.a = t2.a WHERE t2.b = 100，那么在索引遍历阶段就过滤掉 b != 100 的条目，减少回表次数。
Hash Join 在这种场景下反而笨重：
- 必须把整个
t2（哪怕 100 万行）读入内存建哈希表 - 若内存不足，会写磁盘临时文件，IO 放大数倍
- 驱动表每行都要做哈希计算和桶探测，CPU 开销固定偏高
性能影响明显：实测中，驱动表 10 行、被驱动表 10 万行时，Index Join 耗时通常低于 5ms；同等条件下 Hash Join（需强制启用）常超 50ms，且内存占用翻 3 倍以上。
别忽略 B+ 树的缓存友好性和稳定性
B+ 树节点按页存储（默认 16KB），与操作系统页缓存、InnoDB buffer pool 天然对齐。热点索引页常驻内存，后续点查询几乎零磁盘 I/O。Hash Join 的哈希表是散列结构，内存布局随机，缓存命中率低，且每次查询都要重建 —— 无法复用。
容易踩的坑：
- 误以为 “只要加了索引就自动用 Index Join”：实际优化器可能因统计信息不准、
join_buffer_size过大等原因选错算法，要用STRAIGHT_JOIN或USE INDEX强制 - 在
JOIN条件里对字段用函数（ON YEAR(t2.create_time) = YEAR(t1.time)），导致索引失效，退化成 Block Nested-Loop - 联合索引顺序错（如建了
(b, a)却用ON t1.a = t2.a），最左前缀不匹配，B+ 树无法定位起点
真正关键的不是选哪种 Join，而是确保被驱动表的关联字段存在有效索引，并且查询模式与索引结构对齐 —— 否则再好的 B+ 树也白搭。
