SQLHints是嵌入SQL中影响优化器执行计划的指令，用于统计不准、代价偏差等场景；包括INDEX强制索引、LEADING/USE_NL控制连接、NO_PARALLEL抑制并行、NO_MERGE抑制视图合并等。
SQLHints（优化器提示）是在SQL语句中嵌入的指令，用于影响查询优化器生成执行计划的方式。它不是万能开关，而是在特定场景下对优化器“建议”更优路径的补充手段——当统计信息不准确、代价估算偏差大、或存在多表关联/复杂索引策略时，Hint 可以快速干预执行行为，避免重写逻辑或等待统计更新。
强制走指定索引（INDEX / INDEX_SS）
当优化器因统计过期或选择率误判而放弃高效索引时，可用 INDEX 提示明确指定索引。例如：查询订单表中某用户的最新10条记录，但优化器走了全表扫描而非按用户ID+时间排序的联合索引：
SELECT /*+ INDEX(orders idx_user_status_time) */ * FROM orders WHERE user_id = 123 AND status = 'done' ORDER BY create_time DESC FETCH FIRST 10 ROWS ONLY;
注意：若索引列顺序与查询条件/排序不匹配，可能失效；复合索引中前导列未出现在WHERE中，INDEX 仍可能被忽略。此时可尝试 INDEX_SS（索引跳扫）应对非前导列过滤场景。
控制连接顺序与算法（LEADING / USE_NL / USE_HASH）
多表JOIN时，优化器默认按成本估算驱动表和连接方式，但小表驱动大表、或内存充足时倾向哈希连接，这些假设未必成立。使用 LEADING 可固定驱动表顺序，配合 USE_NL 或 USE_HASH 指定算法：
- 小结果集驱动大表且有高选择性索引 → USE_NL + LEADING 小表
- 两表都较大、内存足够、无合适索引 → USE_HASH 更稳定
- 避免优化器错误选择笛卡尔积或嵌套循环导致大量IO → 显式限定驱动表可立竿见影
规避并行执行干扰（NO_PARALLEL / PARALLEL）
OLTP类短查询若被自动并行（如Oracle中PARALLEL_DEGREE_POLICY=AUTO），反而因协调开销拖慢响应；反之，大数据量报表类查询又可能因未启用并行而耗时过长。此时用 NO_PARALLEL 禁用并行，或 PARALLEL(4) 手动指定并行度，比调整系统级参数更精准、低风险。
特别注意：并行Hint需配合目标对象（表或操作符）使用，单独写 /*+ PARALLEL */ 可能无效；且在RAC或资源紧张环境需评估节点间数据分发成本。
抑制视图合并或子查询展开（NO_MERGE / NO_UNNEST）
复杂视图或WITH子句常被优化器自动合并或展开，有时导致执行计划膨胀、重复计算或丢失索引访问路径。例如一个预计算了聚合字段的视图，在主查询加了额外过滤后，合并反而使索引失效：
SELECT /*+ NO_MERGE(v) */ * FROM (SELECT /*+ MATERIALIZE */ ... FROM t1 GROUP BY ...) v WHERE v.total > 1000;
NO_MERGE 阻止视图合并，MATERIALIZE 强制物化中间结果，两者常搭配使用；NO_UNNEST 则保留子查询独立执行，适用于子查询结果集小但关联条件选择性高的情况。
