先查内表有没有索引，因为Nested Loops慢主因是被驱动表连接字段无索引，导致每轮循环全表扫描，10万×100万次比对；EXPLAIN中内表type为ALL或index、key为NULL即确认未走索引。
EXPLAIN里看到Nested Loops但查询卡住，先查内表有没有索引
绝大多数情况下，Nested Loops慢不是算法本身的问题，而是被驱动表（内表）连接字段没索引。优化器以为能快速定位，实际每轮循环都触发一次全表扫描——外表返回10万行，内表100万行，就是10万 × 100万次比对。
-
EXPLAIN中内表的type是ALL或index，且key为NULL，基本等于确认没走索引 - 外表加了
LIMIT 10但优化器没下推，仍按全量估算驱动行数，导致计划失真 - 连接字段存在隐式转换：比如
orders.user_id是BIGINT，users.id是INT，两边索引全失效 - 字符集不一致：
utf8mb4_general_ci关联合utf8mb4_unicode_ci字段，同样触发全表扫
INLJ（Index Nested-Loop Join）生效的三个硬条件
INLJ不是“建了索引就自动用”，它需要同时满足：被驱动表连接字段有索引、驱动表能高效输出行、连接条件符合最左前缀。缺一不可。
- 被驱动表索引必须覆盖
ON中的字段，且最好是选择性高的非空列；复合索引如(a, b)，而ON t1.a = t2.a AND t1.b = t2.b才真正生效 - 驱动表自身也要有索引支撑：如果
WHERE条件没索引，驱动表自己就得先全表扫一遍，再拿结果去嵌套 -
EXPLAIN中看到type为ref或eq_ref、key非NULL、rows远小于表总行数，才算真正走INLJ
别乱调join_buffer_size，它对NLJ几乎没用
调大join_buffer_size只能缓解Block Nested Loop（BNL）的IO压力，对原始Nested Loop Join（NLJ）无实质帮助——因为NLJ根本不走buffer，它只靠索引跳转。
- MySQL默认用NLJ，只有当被驱动表没索引时，才会退化成BNL；此时调
join_buffer_size可能减少内表扫描次数，但治标不治本 - Linux下该值默认256K，若驱动表太大装不下，BNL仍要分多批加载，内表照样被扫多次
- 真正有效的解法永远是：给被驱动表连接字段建索引，而不是堆内存
LEFT JOIN强制左表驱动，INNER JOIN却可能选错表
语法差异直接影响执行路径：LEFT JOIN锁死左表为驱动表，INNER JOIN允许优化器自由交换顺序——但它可能误判，让大表当了外表。
- 典型场景：
users（1万行）、orders（500万行），orders.user_id无索引；LEFT JOIN被迫用users驱动，走INLJ；INNER JOIN却可能选orders当外表，导致中间结果爆炸 - 解决方法不是加hint，而是提前裁剪驱动表：用子查询或CTE过滤，比如
FROM (SELECT * FROM orders WHERE dt >= '2026-08-01') o LEFT JOIN ... - PostgreSQL可用
/*+ Leading(t1 t2) */强制驱动顺序，MySQL 8.0+需用JOIN_ORDERhint，但优先级低于统计信息准确性
真正卡住的从来不是Nested Loops这个词，而是rows和loops背后那张没索引的表——它藏在执行计划最底下，容易被忽略。
