SQL JOIN本质是按条件配对组合，核心算法为嵌套循环连接（小表驱动+索引）和哈希连接（大表等值JOIN），执行计划中通过"Nested loop"或"Hash join"字段可识别。
SQL 中 JOIN 的本质，是把两个表按条件“配对”组合。数据库不会凭空生成结果，而是靠具体算法一步步执行。最常用也最值得深挖的两种是嵌套循环（Nested Loop Join）和哈希连接（Hash Join），它们适用场景不同，性能差异极大。
嵌套循环连接：小表驱动 + 索引是关键
它就像两层 for 循环：外层取一行，内层逐行比对找匹配。但实际效率完全取决于怎么用。
- 没索引时，内层每次都要全表扫描——10 万行驱动表 × 100 万行被驱动表 = 1000 亿次比对，基本不可行
- 有索引时，内层变成一次 B+ 树查找（约 3–4 次磁盘 IO），成本骤降为“驱动表行数 × 单次索引查找”
- MySQL 会自动选小表作驱动表；你也可以用 STRAIGHT_JOIN 强制指定，避免优化器误判
- 适合场景：驱动表结果集小（比如加了高效 WHERE）、被驱动表连接字段有索引、返回数据量不大
哈希连接：大表等值 JOIN 的主力算法
它不依赖索引，靠内存哈希表加速匹配，分两步走：先建表，再探测。
- Build 阶段：把较小表（如 Customers）的连接字段（cust_id）做哈希，存进内存哈希表
- Probe 阶段：扫描大表（如 Orders），对每行计算相同哈希值，直接查表定位匹配项
- 要求连接条件必须是等值（=），且内存要够装下小表哈希结构；不够会退化为落盘哈希，性能下降
- 适合场景：两张大表 JOIN、无可用索引、连接键是等值比较、服务器内存较充裕
怎么判断数据库用了哪种？看执行计划
运行 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE（MySQL 8.0.18+），重点关注 "join_type" 和 "using_join_buffer" 字段：
- 出现 "Nested loop" 或 "Using index condition" → 大概率是索引嵌套循环
- 出现 "Hash join" 或 "Using join buffer (hash join)" → 明确启用哈希连接
- 看到 "Using join buffer (block nested loop)" → 是块嵌套循环，说明没索引又不够用哈希，属于折中方案
别只盯着算法，表顺序和索引才是杠杆点
算法是数据库自动选的，但你能控制的是基础条件：
- 确保 JOIN 条件字段在被驱动表上有索引（尤其是高频关联字段，如 user_id、order_id）
- 用 WHERE 先过滤驱动表，让它真正变小（例如加时间范围、状态筛选）
- 避免 SELECT *，只取需要字段，减少哈希表体积和网络传输开销
- 监控 join_buffer_size 参数，太小会强制退化，太大又浪费内存
