用 /+ leading() / 比 STRAIGHT_JOIN 更可控，但必须配合 EXPLAIN 验证，否则极易适得其反；因其支持多表精细编排、兼容各类 JOIN 且不破坏语义，而 STRAIGHT_JOIN 仅适用于简单 INNER JOIN 场景且易静默失效。
直接说结论：用 /*+ leading() */ 比 STRAIGHT_JOIN 更可控，但必须配合 EXPLAIN 验证，否则极易适得其反。
为什么不能只靠优化器自动选JOIN顺序
MySQL 8.0+ 的优化器在多数简单查询中能选出较优驱动表，但遇到以下情况就容易误判：
- 统计信息陈旧（
ANALYZE TABLE没跑过，或数据突增/突减） - 多层嵌套子查询被提升后，原表别名和实际执行块不一致
- WHERE 条件中存在隐式类型转换（如
INT字段 JOINBIGINT字段），导致索引失效、行数估算严重偏差 - 复合索引覆盖不全，优化器误以为某张表“过滤性高”，实际全表扫描
此时看到 EXPLAIN 中 type=ALL 出现在大表上，且 rows 值远超预期，基本就是驱动表选错了。
leading() 的括号嵌套规则到底怎么读
很多人卡在语法上，不是记不住，而是括号含义和执行逻辑不匹配。关键就一条：最外层圆括号 () 决定内外表顺序，内层括号只管 join 先后，不管谁驱动谁。
-
/*+ leading(t1 t2 t3) */→ 三表按t1 → t2 → t3顺序 join，但每步谁做外表/内表由优化器定 -
/*+ leading((t1 t2 t3)) */→t1先驱动t2（t2是内表），再用t1-t2结果驱动t3（t3是内表） -
/*+ leading(t1 (t2 t3) t4) */→ 先算t2和t3的 join（顺序不定），再把结果和t1、t4按书写顺序连，但不指定哪张是驱动表 -
/*+ leading((t1 (t2 t3) t4)) */→t2和t3先连（无内外约束），再用该结果驱动t1（t1是内表），最后用t1-(t2-t3)结果驱动t4（t4是内表）
注意：leading 中的表名必须用别名，且不能带库名或 schema；如果用了 AS a，就必须写 a，不能写原表名。
什么时候该用 STRAIGHT_JOIN 而不是 leading()
STRAIGHT_JOIN 是粗粒度强制，leading() 是细粒度编排。二者适用场景完全不同：
- 用
STRAIGHT_JOIN：仅当明确知道“先扫 A 再关联 B”一定比优化器选的快，且 A 表加了强 WHERE 过滤（比如status = 'done' AND created_at > NOW() - INTERVAL 1 HOUR），过滤后只剩几百行——这时硬控顺序成本低、见效快 - 用
leading()：多表（≥4 张）、有子查询提升、或需要控制某几表先聚合再对外 join 的场景。例如：先让orders和lineitem关联求出订单明细，再拿这个中间结果去 joincustomer和nation，避免大表customer过早参与嵌套循环 - 千万别混用：
STRAIGHT_JOIN和/*+ leading() */同时出现，MySQL 会忽略后者，且不会报错，只会静默失效
另外，STRAIGHT_JOIN 只支持 INNER JOIN，LEFT JOIN 中若右表被强制提前，语义可能出错；leading() 则无此限制。
验证是否生效的三个必查点
加完 Hint 不等于优化完成，必须立刻查执行计划：
- 看
EXPLAIN FORMAT=TREE输出顶部是否出现/*+ leading(...) */被识别的提示；若没出现，说明语法错误或表名不匹配 - 检查各表的
possible_keys和key是否命中你预设的索引——Hint 只管顺序，不管索引是否存在；顺序对了但没索引，照样慢 - 对比
rows预估值：驱动表的rows应显著小于被驱动表；若发现被驱动表rows是驱动表的几十倍，说明 Hint 没起作用，或统计信息严重失真
最容易被忽略的是：Hint 生效了，但某张被驱动表的 JOIN 字段上没有索引，导致它仍被全表扫描——这时候你看到的“顺序对了”，只是表面正确。
