小表驱动大表本质是减少外层循环次数，由nested loop join算法决定：外层行数越少，总匹配次数越少；真正起作用的是过滤后的小结果集，而非原始表大小。
小表驱动大表本质是减少外层循环次数
它不是数据库“偏好”小表，而是嵌套循环连接（Nested Loop Join）这种默认执行算法的物理限制决定的：外层表每取一行，内层表就要做一次匹配动作。外层行数越少，总匹配次数就越少——这是硬性数学关系，不是优化器的主观选择。
常见错误现象：EXPLAIN里看到左表 type=ALL、右表 type=ref，但查询仍慢；或执行计划中出现 Using join buffer (block nested loop)，说明已退化为低效扫描。
- 小表 100 行 × 大表索引查找（约 3–4 次 IO）≈ 400 次 IO
- 大表 100 万行 × 小表索引查找 ≈ 400 万次 IO —— 差 1 万倍
- 真正起作用的是“过滤后的小结果集”，不是原始表大小。比如加了
WHERE create_time > '2026-06-01'的订单表，可能比用户表还小 -
STRAIGHT_JOIN可强制指定顺序，但会关闭优化器重排，仅在明确知道优化器误判时才用
LEFT JOIN 里小表驱动大表根本没得选
LEFT JOIN 的左表固定为驱动表，这是语法语义决定的，优化器不能交换顺序。你写 big_table LEFT JOIN small_table，MySQL 就必须全扫 big_table，哪怕 small_table 有完美索引也无济于事。
使用场景：报表类查询常需保留主表全部记录，但若主表本身就是大表（如日志表），性能必然崩塌。
- 现象：
EXPLAIN显示左表rows极高，右表key为空，但Extra却写着Using where—— 实际是 ON 条件失效，退化成笛卡尔积再过滤 - 解法优先级：先尝试把逻辑改成
INNER JOIN，让优化器自由选驱动表；不行就对左表加WHERE提前缩小结果集 - ON 中写过滤条件（如
ON u.id = o.user_id AND o.status = 1）只影响右表匹配行为，不减少左表扫描行数
索引建在被驱动表的关联字段上才有效
驱动表选得再小，如果被驱动表没索引，Nested Loop Join 就会变成全表扫描 × 驱动表行数，直接触发 Block Nested Loop 或更糟的 Simple Nested Loop。
参数差异：join_buffer_size 影响块嵌套循环的缓存效率，但治标不治本；真正关键的是被驱动表的 JOIN 字段是否有可用索引。
- 错误做法：只给驱动表建索引，或给被驱动表建了索引但字段类型不一致（如
INTvsVARCHAR），导致索引无法命中 - 正确做法：确保被驱动表的
ON条件右侧字段（如order.user_id）有单列索引或作为联合索引最左前缀 - 避免在
ON中对字段用函数，如ON YEAR(o.pay_time) = 2026，会让索引彻底失效
哈希连接（Hash Join）绕过了“小表驱动”依赖，但有条件
MySQL 8.0.19+ 默认启用 hash_join=on 后，大表等值 JOIN 可跳过索引依赖，靠内存哈希表加速。但它不改变“小表更适合 Build 阶段”的事实——哈希表要全量加载小表数据，内存不够就会落盘，性能断崖下跌。
性能影响：哈希连接对等值 JOIN 友好，但一旦 ON 条件含 >、LIKE 或函数，就会自动回退到嵌套循环。
- 判断是否启用：
EXPLAIN FORMAT=TREE中出现Hash join或Using join buffer (hash join) - 内存限制：
join_buffer_size要大于小表哈希后体积，否则退化为Block Nested Loop - 别指望它拯救没索引的大表 JOIN：哈希连接仍要求小表能完整载入内存，且只支持等值条件
EXPLAIN 和实际 rows 数去验证。
