2025-10-22

오늘 배운 것

Q1. MySQL 조인 최적화에서 Exhaustive와 Greedy 알고리즘의 차이를 설명해보세요.

A.

Exhaustive는 가능한 모든 조인 순서를 다 계산해 최적의 조합을 찾는 방식이라 정확하지만 테이블이 많아지면 20! 수준으로 비용이 폭증합니다.

Greedy는 일부 후보만 평가해 빠르게 “그나마 최선”을 고르는 방식으로, optimizer_search_depth 만큼만 조합을 평가하고 그 중 최소 비용을 기반으로 단계적으로 조인 순서를 확정합니다.

실무에서는 조인 테이블이 많을수록 Greedy가 자동으로 개입해 최적화 시간을 줄이는 구조입니다.

Q2. MySQL 8.0 이후 BNL / HASHJOIN 힌트 의미를 어떻게 이해해야 하나요? 그리고 언제 쓰나요?

A.

8.0.20 이후 BNL 힌트는 이름만 남고 사실상 “해시조인을 강제”하는 힌트입니다.

해시조인은 인덱스 없는 조인에 유리하고, 인덱스가 잘 잡혀 있으면 해시조인은 거의 사용되지 않습니다.

즉 “해시조인 vs 인덱스 네스티드 루프”의 선택 문제이며, 인덱스 기반 조인이 가능한 상황에서는 해시조인을 명시해도 채택되지 않는 것이 정상입니다.

• 조인 조건이 되는 칼럼의 인덱스가 적절히 준비되어 있다면 해시 조인은 거의 사용되지 않음
  • 왜?
    • 해시조인과 블록 네스티드 루프 조인은 비 인덱스 조인에서 유용한것
    • 인덱스가 있다면 조인 키로 내부 테이블 인덱스를 바로 룩업 하는 인덱스 네스티드 루프 조인을 사용하는 것이 좋음

Q3. STRAIGHT_JOIN vs JOIN_ORDER vs JOIN_PREFIX 차이를 어떻게 이해하면 되나요?

A.

STRAIGHT_JOIN은 FROM에 적힌 순서를 그대로 조인 순서로 고정하는 강한 힌트입니다.

반면 옵티마이저 힌트 계열인 JOIN_ORDER/JOIN_PREFIX/JOIN_SUFFIX는 “전부 강제할지 일부만 강제할지”를 선택적으로 지정할 수 있습니다.

• JOIN_ORDER(a,b,c) → a→b→c 순서 전체 강제
• JOIN_PREFIX(a,b) → 드라이빙만 a→b 강제, 이후는 옵티마이저 자유
• JOIN_SUFFIX(x,y) → 마지막 조인 순서만 x→y 고정

실무에서는 전체 고정보다 “드라이빙만 강제하고 나머지는 옵티마이저에게 맡기는” JOIN_PREFIX가 안전합니다

Q4. MySQL 서버 옵티마이저가 전문 검색 인덱스를 가중치를 두어서 실행계획 수립하는 이유가 뭘까요?

전문 검색 인덱스는 긴 문장 안에서 단어를 찾는 데 특화된 인덱스라서, 일반 인덱스보다 이런 조건을 훨씬 빠르게 처리한다는 것이 거의 기본 전제다. 그래서 옵티마이저는 “문자 검색이면 이게 더 유리하다”라고 보고, 다른 인덱스가 있어도 전문 검색 인덱스를 먼저 쓰려고 한다.