大表在嵌套循环join中极慢，因其导致上亿次随机i/o；根本原因是被驱动表无索引且数据量大，或驱动表选错、隐式类型转换致索引失效。
为什么大表在嵌套循环JOIN里特别慢
MySQL 的 Nested Loop Join 本质是拿驱动表的每一行，去被驱动表里逐行匹配。如果被驱动表没走索引、又特别大（比如千万级），那一次 JOIN 就可能触发上亿次随机 I/O —— 这不是“慢”，是卡死。
常见错误现象：EXPLAIN 显示 type=ALL 或 type=index 且 rows 值极大；SHOW PROCESSLIST 中长期卡在 Sending data；慢查询日志里 Rows_examined 远超结果集行数。
- 驱动表选错：把大表当驱动表，小表反而被反复扫描
- 被驱动表缺失关联字段索引：哪怕只是
WHERE条件里用了，JOIN 字段没索引照样全表扫 - 隐式类型转换：比如
INT字段 JOINVARCHAR字段，索引失效，退化成全表比对
怎么强制让小表当驱动表
MySQL 5.7+ 默认用 JOIN_ORDER 启发式选择驱动表，但面对大表经常误判。不能靠猜，得显式干预。
- 用
STRAIGHT_JOIN替代JOIN：它强制按FROM后顺序执行，左边必须是驱动表。例如：SELECT * FROM small_table STRAIGHT_JOIN big_table ON small_table.id = big_table.small_id - 避免在大表上写
WHERE条件后还让它当被驱动表：条件尽量下推到驱动表，或提前用子查询/临时表过滤大表 - 检查
EXPLAIN的table列顺序：第一行是驱动表，确认它确实是小表或已过滤后的结果集
被驱动表索引必须覆盖 JOIN 条件和 WHERE 条件
只给 ON 字段建索引不够。如果还有 WHERE big_table.status = 1，而索引只有 (small_id)，MySQL 仍要回表查 status，甚至放弃索引走全表。
- 联合索引顺序按“等值查询字段 + 范围查询字段”排：比如
ON b.small_id = s.id AND b.type = 'user'+WHERE b.created_at > '2024-01-01'，索引应为(small_id, type, created_at) - 避免前导列不参与查询：比如索引是
(a, b, c)，但查询只用b = ?，索引完全失效 - 注意
NULL值：如果JOIN字段允许NULL，而索引没包含该约束，部分优化器版本可能拒绝使用索引
实在没法避免大表驱动时，用物化临时表切分
当业务逻辑硬性要求大表在左（比如要按大表主键排序分页），又无法加有效索引，就得绕开嵌套循环本身。
- 用
CREATE TEMPORARY TABLE先提取小表关键字段（如 ID、JOIN 键），加上索引再 JOIN：相当于把小数据集“固化”进内存临时表，减少重复查找开销 - 对大表做分区裁剪：如果大表按时间分区，
WHERE条件能命中单个分区，JOIN 效率会指数级提升 - 慎用
IN (subquery)：MySQL 8.0.20+ 对IN子查询做了物化优化，但老版本容易退化成 N+1 查询，不如显式建临时表可控
真正难的不是语法，是判断哪张表在哪个查询上下文里算“小”——它可能随 WHERE 条件变化而变化。别信表总行数，要看实际参与 JOIN 的行数。
