不能直接指望hash_aj和hash_sj“修复oom”，它们仅强制优化器选择特定连接方式，若内存参数未调、数据量过大或执行计划不合理，加提示反而加剧内存耗尽；真正生效需满足pga配置正确、os共享内存参数匹配且sql确因nl导致逻辑读爆炸。
Oracle多表连接触发ORA-04030或ORA-27102时，HASH_AJ和HASH_SJ真能解决问题？
不能直接指望这两个提示“修复OOM”。它们只是强制优化器选择特定连接方式（HASH_AJ用于半连接，HASH_SJ用于反连接），但若底层内存参数未调、数据量过大或执行计划本身不合理，加了提示反而可能让内存分配更集中、更快触顶。
常见错误现象是：SQL在开发环境跑得通，一上生产就报 ORA-04030: out of process memory 或 ORA-27102: out of memory，且v$session_longops显示大量HASH JOIN或SORT操作正在消耗PGA。
真正起作用的前提是：
- 数据库已正确配置
pga_aggregate_target（不是仅靠sga_target） - 操作系统级共享内存参数（
kernel.shmall、kernel.shmmax）与物理内存匹配 - 该SQL确实因嵌套循环（
NESTED LOOPS）导致大量逻辑读+临时段膨胀，而非HASH本身内存不足
什么时候该用HASH_AJ而不是默认计划？
HASH_AJ适用于形如 WHERE col IN (SELECT ...) 的半连接场景。默认优化器可能选NESTED LOOPS SEMI，对驱动表每行都执行一次子查询，若驱动表有10万行、子查询每次扫描1万行索引，逻辑读就达10亿次——间接推高PGA中sort/hash区压力。
使用条件很具体：
- 子查询返回结果集不大（建议
- 子查询无相关列（即不依赖外层值），否则
HASH_AJ不生效 - 确认
optimizer_features_enable版本支持该提示（11gR2+基本都支持）
SELECT /*+ HASH_AJ(t2) */ t1.id, t1.name FROM orders t1 WHERE t1.cust_id IN ( SELECT /*+ NO_UNNEST */ t2.cust_id FROM customers t2 WHERE t2.status = 'ACTIVE' );注意：
NO_UNNEST常需配合使用，否则优化器可能先做unnest再忽略HASH_AJ。
HASH_SJ在NOT EXISTS场景下为何有时更省内存？
HASH_SJ对应NOT EXISTS或NOT IN（非空安全时）。默认计划若走NESTED LOOPS ANTI，同样面临“外层每行触发一次内表探测”的问题；而HASH_SJ会把内表（如customers）构建哈希表一次，外层全表扫描时仅做哈希探查——减少重复I/O和排序需求。
但风险点在于：
- 若内表太大（比如千万级
customers），构建哈希表本身就会吃光PGA -
NOT IN含NULL时行为异常，HASH_SJ不会自动规避，必须确保内表关联字段非空 - 并行度高时，每个PX slave都会独立建哈希表，总内存消耗 = 并行度 × 单表哈希内存
SELECT /*+ HASH_SJ(t2) */ t1.* FROM sales t1 WHERE NOT EXISTS ( SELECT 1 FROM returns t2 WHERE t2.sale_id = t1.id AND t2.reason = 'FRAUD' );
比加提示更关键的三件事
所有提示都建立在底层资源可控的前提下。很多团队花半天调SQL，却忽略这三点：
- 检查
pga_aggregate_target是否被设成0或过小（例如8G库只配512M），且确认workarea_size_policy = AUTO - 运行
SELECT * FROM v$pgastat，重点关注total PGA allocated和cache hit percentage——若命中率低于60%，说明频繁spill到temp表空间，本质是PGA不够 - 用
DBMS_XPLAN.DISPLAY_CURSOR看真实执行计划，确认HASH_AJ/HASH_SJ是否真的被采纳（NOTE部分会写“hint applied”），还是被优化器无视
pga_aggregate_target比硬加提示见效更快；而长期方案一定是拆分大查询、加物化中间结果、或改用分区剪枝——提示只是手术刀，不是止痛药。
