LEADING是Oracle 19c中唯一可靠控制JOIN顺序的Hint，精确指定驱动表与被驱动表关系；ORDERED仅保持FROM书写顺序且仅对嵌套循环有效；USE_NL/USE_HASH必须与LEADING配合使用才生效。
LEADING 是控制 JOIN 顺序的唯一可靠方式
Oracle 19c 的 CBO 完全忽略 SQL 中 FROM 子句的书写顺序，LEADING 是唯一能精确干预 JOIN 物理执行路径的 Hint。它不只指定“谁先连谁”，还隐含定义了内外表关系——括号内靠左的是驱动表（外表），靠右的是被驱动表（内表）。
常见错误是把 LEADING(t1 t2 t3) 理解为线性顺序，实际它等价于 ((t1 t2) t3)，即 t1 驱动 t2，再用结果驱动 t3。若想让 t2 驱动 t3、t1 仅做过滤前置，必须写成 LEADING(t1 (t2 t3))。
-
LEADING中所有表名必须使用别名，且该别名已在 FROM 中声明 - 不能出现循环依赖，如
LEADING((t1 t2) (t2 t3))会直接报错 ORA-00600 - 如果目标是“小表驱动大表”，但小表在 SQL 里写在后面，
LEADING就是唯一补救手段
ORDERED 只保 FROM 顺序，不控内外表
ORDERED 是 LEADING 的简化替代，但它只强制优化器按 FROM 子句从左到右执行嵌套循环（Nested Loops），不指定哪张表是驱动表、哪张是被驱动表。对 HASH JOIN 或 MERGE JOIN 完全无效。
典型适用场景：你有一组已过滤到几十行的小结果集表，按书写顺序天然适合嵌套循环，且不想深究内外表细节。例如：
SELECT /*+ ORDERED */ * FROM orders o JOIN customers c ON o.cust_id = c.cust_id JOIN regions r ON c.region_id = r.region_id WHERE o.status = 'shipped' AND r.country = 'CN';
- 必须确保左侧表（
orders）经过 WHERE 过滤后确实很小，否则驱动表过大，性能反而更差 - 一旦优化器选择 HASH JOIN，
ORDERED就彻底失效，不会降级为其他行为 - 它不兼容
USE_NL或USE_HASH等算法 Hint，混用可能被整体忽略
USE_NL / USE_HASH 必须和 LEADING 配对才生效
单独写 /*+ USE_NL(t2) */ 几乎总是失效。因为 USE_NL 只表示“如果 t2 是内表，就用 NL”，但优化器仍可能把 t2 当作外表。真正起作用的是 LEADING 定义的驱动链路。
正确写法必须显式锚定关系：
-
/*+ LEADING(t1 t2) USE_NL(t2) */→ t1 驱动 t2，走 NL -
/*+ LEADING(t1 (t2 t3)) USE_HASH(t2,t3) */→ t1 先执行，t2 和 t3 之间走 HASH JOIN -
USE_NL后只能跟一个表名（内表），USE_HASH和USE_MERGE后必须跟两个表名（参与该次 JOIN 的一对）
容易被忽略的是：加了 Hint 不等于执行计划真变了。务必用 EXPLAIN PLAN FOR 查看输出中是否出现 NESTED LOOPS、HASH JOIN 等真实操作符，而不是只看到 Join Filter 或 Hash Cond。
检查执行计划时最容易漏掉的关键点
Hint 生效的前提是统计信息准确、索引存在且可用。哪怕 LEADING 和 USE_NL 写得完全正确，只要被驱动表的连接列上没有索引，优化器就会因预估 NL 成本过高而弃用该路径，执行计划里仍显示 HASH JOIN，并可能附带 “hint rejected” 提示。
- 用
SELECT * FROM user_indexes WHERE table_name = 'T2'确认索引存在 - 用
SELECT column_name FROM user_ind_columns WHERE index_name = 'IDX_T2_JOIN_COL'验证索引列顺序匹配 JOIN 条件 - 执行
DBMS_STATS.GATHER_TABLE_STATS更新统计信息，避免旧数据误导优化器
最隐蔽的问题是：Hint 在开发环境生效，上线后因数据分布变化（比如某列值倾斜加剧）导致成本估算偏移，执行计划悄然回退。这类问题必须在生产数据量级下验证，不能只看小数据集的 EXPLAIN 输出。
