驱动表选错会导致JOIN性能从O(n+m)退化为O(n×m)；其核心在于外层循环次数取决于驱动表过滤后的行数，而非原始大小，且受统计信息、索引选择性及LEFT JOIN语义约束。
驱动表选错，JOIN性能可能直接降为O(n×m)，而不是O(n+m)——这不是理论风险，是线上高频翻车点。
驱动表决定嵌套循环的外层规模
MySQL所有JOIN算法（NLJ、BNL、Hash Join）都依赖“驱动表→被驱动表”的单向匹配逻辑。外层循环次数 = 驱动表过滤后的行数。如果误把100万行的表当驱动表，哪怕被驱动表只有100行，也要循环100万次；而反过来，若驱动表过滤后只剩500行，总匹配次数就压到500×100=5万次。
常见错误现象：EXPLAIN中type列为ALL且rows值巨大，但WHERE条件明明已经筛掉99%数据——问题出在优化器没选对驱动表，因为它看的是“过滤后行数”，不是“原始表大小”。
- INNER JOIN由优化器自动选，但依赖
ANALYZE TABLE更新的统计信息，过期统计会导致误判 - LEFT JOIN强制左表为驱动表，哪怕右表更小、索引更好，也无法绕过
- 用
STRAIGHT_JOIN可强制按书写顺序执行，但必须确认左表确实是过滤后的小结果集
驱动表影响索引能否生效
Index Nested-Loop Join（NLJ）要求被驱动表的ON字段有索引。但索引是否真被用上，取决于驱动表输出的关联值是否“足够离散”。如果驱动表返回10万条重复的user_id，即使被驱动表有INDEX(user_id)，MySQL也可能放弃走索引，退化为全表扫描+临时哈希匹配。
使用场景：当EXPLAIN显示type=ref但rows异常高，或Extra出现Using join buffer，大概率是驱动表输出了大量重复值，导致索引选择性失效。
- 检查驱动表输出的关联字段分布：
SELECT COUNT(DISTINCT user_id) / COUNT(*) FROM driver_table WHERE ...，比值低于0.1需警惕 - 避免在驱动表中用
SELECT *再JOIN，应先用子查询或CTE过滤并去重关键关联字段 - 复合索引要覆盖被驱动表的全部ON条件和WHERE过滤字段，否则仍可能回表或失效
驱动表选择错误会放大LEFT JOIN的NULL陷阱
LEFT JOIN语义上必须保留左表全量，所以左表天然成为驱动表。一旦右表（被驱动表）缺少索引，或者ON条件写错（比如漏掉AND status = 'active'），就会触发全表扫描+临时表，且WHERE里对右表字段的等值判断（如WHERE u.status = 'active'）会直接过滤掉所有NULL行，让LEFT JOIN实际变成INNER JOIN。
容易踩的坑：把本该在ON里的右表过滤条件塞进WHERE，既没保住NULL行，又让优化器无法利用右表索引加速匹配。
- 正确写法：
LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active' - 错误写法：
LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'（丢失无用户订单） - 若右表数据量大且无索引，优先考虑改用
INNER JOIN+STRAIGHT_JOIN反转驱动关系，而非硬扛LEFT JOIN
真正难的不是“怎么选驱动表”，而是意识到：驱动表不是SQL里写的那个“左”或“右”，而是优化器根据过滤后行数、索引可用性、字段选择性综合算出来的结果——它可能和你写的顺序完全相反，也可能因为统计信息陈旧而彻底失准。
