EXPLAIN中大表在驱动位导致rows数爆炸，是因为Index Nested-Loop Join算法下外层循环次数等于驱动表匹配行数，100万行即至少100万次索引查找，连第三表更易达千万级扫描；关键信号是type为ALL/index、rows接近总行数且Extra含Using temporary; Using filesort。
EXPLAIN里看到大表在驱动位，为什么rows数爆炸？
因为MySQL默认用Index Nested-Loop Join，外层循环次数 = 驱动表匹配行数。如果驱动表是100万行的大表，哪怕被驱动表只查1次索引，总索引查找次数也至少是100万次；若再连第三张表，就是100万 × 每行匹配数，极易突破千万级扫描量。
关键信号：EXPLAIN中type列出现ALL或index（非覆盖）、rows接近表总行数、Extra出现Using temporary; Using filesort——这三者同时出现，基本可断定驱动顺序已失控。
小表驱动大表不是经验，是算法硬约束
对Index Nested-Loop Join来说，“小表驱动”不是为了“省事”，而是避免内层重复扫描的刚性需求。PostgreSQL的Hash Join同样依赖小表构建哈希表，若把大表当build side，内存直接溢出落盘，I/O飙升。
实操要点：
- 用
EXPLAIN FORMAT=TREE确认真实驱动顺序，别信SQL书写顺序 - 给被驱动表的
ON字段建B+树索引，且类型、字符集、是否允许NULL必须与驱动表字段严格一致 - 统计信息过期时优化器会误判表大小，定期执行
ANALYZE TABLE
STRAIGHT_JOIN能救急，但会埋雷
STRAIGHT_JOIN强制按SQL顺序执行JOIN，绕过优化器重排。它在数据分布稳定、中间结果可控的场景下有效，比如主表10万行 + 维度表500行 + 状态字典表20行。
但风险明显：
- 一旦某张表数据突增（如日志表单日写入暴涨），原本的小表变大表，
STRAIGHT_JOIN会让性能断崖下跌 - 它禁用所有优化器决策，包括索引选择、条件下推等，可能让本可用的
range扫描退化为ref - 跨库或不同引擎JOIN时，
STRAIGHT_JOIN无法解决隐式转换导致的索引失效
LEFT JOIN后WHERE过滤右表字段，等于悄悄改写成INNER JOIN
这是最隐蔽的“驱动表失效”场景：你写了LEFT JOIN b ON a.id = b.a_id，又在WHERE里加了b.status = 'paid'，MySQL实际执行时会先完成LEFT JOIN，再过滤，结果所有b.status IS NULL的左表记录全被干掉。
后果比性能差更严重——逻辑错误。而执行计划里Extra列出现Using where且涉及右表字段，就是危险信号。
正确做法：
- 右表过滤条件必须写进
ON子句：LEFT JOIN b ON a.id = b.a_id AND b.status = 'paid' - 检查
EXPLAIN输出中rows是否异常放大，尤其对比去掉该WHERE前后的值 - 用
SELECT COUNT(*) FROM (LEFT JOIN ...)验证结果集行数是否符合左表基数
真正卡住性能的，往往不是JOIN本身，而是驱动表选错后引发的嵌套扫描雪崩、临时表落盘、连接池排队这三重连锁反应。一个rows字段翻10倍，背后可能是磁盘I/O涨100倍。
