explain的type和extra字段是判断join算法的关键线索：type为ref/range且extra无using join buffer，大概率走index nested-loop join；出现using join buffer则退化为block nested-loop；type=all配合大rows值表明驱动表选择错误或缺失索引。
看 EXPLAIN 的 type 和 Extra 字段
数据库不会直接告诉你用了哪种 JOIN 算法，但 EXPLAIN 输出里的 type 和 Extra 是最直接的线索。比如：
-
type = ref或range且Extra里没出现Using join buffer，大概率走了Index Nested-Loop Join（有索引支撑） -
Extra出现Using join buffer (Block Nested Loop)，说明退化到了低效的块嵌套循环，被驱动表在反复全表扫描 -
type = ALL配合大表行数，基本确认驱动表选错或关联字段没索引
查驱动表是否真的“小”
所谓“小表驱动大表”，不是看原始数据量，而是看经过 WHERE 过滤后实际参与 JOIN 的行数。很多人误以为 users 表比 orders 小，就该放左边当驱动表——但如果加了 WHERE status = 'pending' 后 orders 只剩 100 行，而 users 没过滤，那它才是事实上的“大驱动表”。
- 用
EXPLAIN的rows列对比各表预估扫描行数 - 关注
filtered列：值越低，说明该表 WHERE 条件选择性越差，越不适合作为驱动表 - 如果发现大表被选为驱动表且
type = ALL，优先检查它的过滤条件是否可前置，或考虑用STRAIGHT_JOIN强制顺序（MySQL）
验证 JOIN 字段是否真能走索引
索引存在 ≠ 能用上。常见失效场景比想象中多：
- 字段类型不一致：
INT对VARCHAR、SIGNED对UNSIGNED，会触发隐式转换，索引失效 - ON 中用了函数：
ON YEAR(a.dt) = YEAR(b.dt)或ON LOWER(a.name) = LOWER(b.name)，优化器无法下推索引扫描 - 复合索引顺序错位：比如
INDEX (a_id, status)，但 JOIN 条件只用到status，而a_id是范围查询，那这个索引对 JOIN 无效 - 字符集或 collation 不同：哪怕都是
VARCHAR，utf8mb4_0900_as_cs和utf8mb4_general_ci比较时也可能放弃索引
留意哈希/排序连接是否被真正启用
MySQL 8.0+ 支持 Hash Join，但默认只在内存充足、小表能完全载入、且是等值 JOIN 时才启用；PostgreSQL 和 Oracle 更积极。别只看文档说“支持”，得实测：
- MySQL 下执行
EXPLAIN FORMAT=TREE，看到-> Hash join才算真正用了 - PostgreSQL 用
EXPLAIN (ANALYZE, BUFFERS)，出现Hash Cond行表示启用哈希连接 - 如果预期能走
Sort-Merge却没走，检查两表 JOIN 字段是否有对应索引（如ORDER BY id的索引），以及work_mem是否足够支撑排序
真正容易被忽略的是：JOIN 算法选择不是静态配置项，它依赖实时统计信息。ANALYZE TABLE 没跑过、或者数据分布剧变后未更新，优化器就可能做出明显错误的决策——这点比写法本身更隐蔽。
