데이터베이스 /*+ordered use_nl */ 힌트를 쓰면 무조건 성능이 좋은걸까?

 

 

 

 

 

/*+ ordered use_nl */ 힌트를 사용하면 성능이 좋아질 수도 있지만, 반대로 성능이 급격히 나빠질 수도 있습니다.

 

힌트는 옵티마이저가 선택하는 기본 실행 계획보다 더 나은 것을 사람이 직접 제시할 수 있을 때만 효과적입니다.

 

---

🔍 /*+ ordered use_nl */ 설명

✅ ordered

• 옵티마이저에게 FROM 절에 나온 순서대로 조인을 수행하라고 지시합니다.
• 기본적으로는 옵티마이저가 테이블 순서를 바꿔 최적화를 시도합니다.

✅ use_nl

• Nested Loop Join (중첩 반복 조인) 을 사용하라고 지시합니다.
• 일반적으로 작은 테이블을 먼저 읽고, 큰 테이블을 조건에 따라 반복 접근하는 방식입니다.

---

⚠️ 언제 좋은 성능이 나올까?

성능 향상이 되는 경우:

• 첫 번째 테이블이 매우 작을 때 (드라이빙 테이블)
• 두 번째 테이블에 인덱스가 잘 걸려 있을 때
• 조인 조건이 잘 필터링되어 반복 접근의 비용이 낮을 때

예:

SELECT /*+ ordered use_nl */ 
a.*, b.* 
FROM small_table a, large_table b 
WHERE a.key = b.key
;

---

❌ 언제 성능이 나빠질까?

• 조인 순서가 비효율적일 경우 (예: 큰 테이블이 앞에 오면)
• 인덱스가 없어서 Nested Loop가 Full Scan으로 반복되면 매우 느려짐
• 옵티마이저가 기본적으로 더 나은 실행 계획을 이미 선택하고 있었던 경우

예: 아래는 매우 비효율적인 경우

SELECT /*+ ordered use_nl */
  a.*, b.*
FROM big_table a, other_big_table b
WHERE a.id = b.id

 

 

이 경우, 옵티마이저는 Hash Join이나 Merge Join을 원할 수 있지만 힌트가 강제로 비효율적인 방법을 사용하게 합니다.

---

✅ 권장사항

상황	추천 여부
옵티마이저가 잘못된 실행계획을 선택할 때	✅ 힌트 사용 고려
조인 순서나 방식이 확실히 효율적일 때	✅ 힌트 사용 고려
기본 실행 계획이 잘 나올 때	❌ 힌트 사용 자제
성능 테스트 없이 무조건 힌트 사용	❌ 위험함

 

---

🔧 팁

• EXPLAIN으로 힌트 전후 실행 계획과 비용을 비교하세요.
• 힌트를 쓸 경우에도 쿼리 성능 테스트는 필수입니다.
• /*+ recompile */ 힌트도 함께 써서 옵티마이저가 힌트를 반영하도록 강제할 수 있습니다.

---

📌 결론

/*+ ordered use_nl */는 무조건 성능이 좋은 힌트가 아닙니다.
오히려 상황에 따라 성능을 망칠 수도 있으므로, 실행 계획 분석 및 테스트 후 신중하게 사용해야 합니다.