인덱스 분할, 병합에 따른 인덱스 적용 기준과 OPTIMIZE TABLE

37 asked

0

안녕하세요 soap님 질문주셔서 감사합니다!! 먼저 새해가 지났지만 복 많이 받으시고 건강하시기를 바랄게요 ㅎㅎ 하나하나 개요를 나눠서 설명드릴게요.

질문1 : 인덱스 분할/병합 관점에서 “걸어도 된다”는 결론에 도달하는 과정

현실적으로 그런 케이스는 거의 없습니다. 저도 그렇게 사용해 본적이 없고 저와 함께 강의를 만드시는 분들도 그런 과정을 통해서 판단을 하지 않아요.

왜냐하면 그건 트래픽의 유형에 따라서 너무나도 달라지는 값이기 떄문입니다. 그래서 무언가 기준을 잡고 이 기준을 넘어서면 설정한다. 이런식의 사고 과정이 아니라 그냥 읽기 트래픽에 집중한다. 이 부분만을 명심하시면 좋을꺼같아요.

그래서 저는 보통 다음 순서로 판단합니다:

1. 실제 쿼리 패턴 확인 (슬로우 쿼리, 실행 계획)

2. 풀스캔 비용 추정

3. 해당 인덱스가 선택될 가능성 확인 (Cardinality, Selectivity)

4. 쓰기 부하 패턴 분석 (INSERT/UPDATE 비율)

그래서 핵심은 "이 인덱스가 없으면 실제로 서비스가 느려지는가?" 이 부분에 집중하시면 되는 겁니다. 읽기 쿼리가 문제가 없다면 굳이 쓰기 비용을 늘릴 필요는 없기 떄문이에요.

질문2 : 인덱스 분할(split)이 실제로 문제가 되는 경우

여러분들이 일반적으로 사용하는 MySQL은 InnoDB를 사용하고 있고, 이 InnoDB의 B-Tree 인덱스는 삽입하는 과정에서 페이지가 가득 차다면 분할이 발생하게 됩니다.

이 과정에서는 여러가지 작업이 일어나죠

• 페이지 복사

• 포인터 재정렬

• redo log 증가

• 잠금 범위 확장 등등

근데 여기서 중요한거는 이 많은 과정에서 우리는 이 두가지에 집중을 해야하는거에요.

• PK가 AUTO_INCREMENT라면 → 대부분 우측 삽입 → split 빈도 낮음

• 랜덤 키(UUID 등)라면 → 중간 삽입 → split 빈도 높음

그래서 UUID를 PK로 사용했을 떄에는 인덱스를 조심하셔야 하고, 조회가 압도적으로 많다면 그냥 인덱스를 걸어버리는 과정으로 이해하시면 됩니다.

• 무작위성만을 조심하면 될 꺼 같아요.

질문3 : 라이브 환경에서의 OPTIMZE TABLE

이건 이해하신것처럼 최후의 수단이 맞습니다. 왜냐하면 사실상 해당 과정을 진행하면

• 테이블 재생성

• 인덱스 재구성

• 데이터 재정렬

• 메타데이터 락 발생

이런 문제들이 존재하기 떄문이에요.

• 물론 8.0이상에서는 online DDL이 가능하죠. 그래서 가능은 하지만 갑작스럽게 리소스 사용량이 급증한다는 문제가 있습니다.

그래서 OPTIMZE TABLE이 어떤 부분에서 위험한지 이해하시고 내가 이걸 이 상황에 적용해도 문제가 없는지 객관적인 부분들을 검토해보시면 좋지 않을까싶어요.

질문 감사합니다!!

0

안녕하세요, 인프런 AI 인턴입니다. soap님.

인덱스의 분할 및 병합을 고려할 때, 인덱스 적용의 기준은 데이터베이스 성능 최적화의 핵심 요소 중 하나입니다. 인덱스는 읽기 성능을 크게 향상시키지만, 잘못 설계된 인덱스는 쓰기 성능에 영향을 줄 수 있습니다. 따라서, 인덱스를 설정할 때 다음과 같은 요소를 고려합니다.

인덱스 설정 시 고려사항

1. 읽기/쓰기 비용의 균형:

   • 읽기 비용: 인덱스를 추가하면 데이터를 조회하는 속도가 빨라집니다. 하지만 각 쿼리의 실행 계획을 상세히 검토하여 인덱스가 얼마나 효율적인지 확인해야 합니다.
     
   • 쓰기 비용: 인덱스가 많아질수록 삽입, 갱신, 삭제 시 더 많은 비용이 발생합니다. 이는 인덱스 업데이트를 위한 부가 작업 때문입니다.
     

2. TPS(Transactions Per Second)와 패턴 분석:

   • 주로 읽기와 쓰기 패턴을 분석하여 인덱스가 필요한지 결정합니다. 예를 들어, 읽기 작업이 빈번하고 TPS가 높은 시스템에서는 읽기 성능을 우선시하는 인덱스 설계가 필요할 수 있습니다.
     

3. Redo Log 및 디스크 사용량:

   • 인덱스가 추가되면 redo log 크기가 증가할 수 있습니다. 이는 DB 복구에 영향을 미칠 수 있으므로, I/O 대기 시간과도 관련됩니다. 따라서, 시스템의 I/O 성능에 따라 인덱스의 영향을 측정해보는 것이 좋습니다.
     

4. 테이블 및 인덱스 크기:

   • 인덱스가 커질수록 메모리 자원을 더 많이 소모합니다. 만약 인덱스 크기가 메모리 한도를 초과한다면, 쿼리 성능이 저하될 수 있습니다. 이러한 경우에는 인덱스를 효율적으로 작게 유지할 필요가 있습니다.
     

정량적인 측면에서는 위 요소들을 모니터링하고, 인덱스 추가 전후의 성능 차이를 벤치마크하는 방법을 사용할 수 있습니다.

아래 링크를 통해 인덱스 최적화와 관련된 더 많은 정보를 얻으실 수 있습니다:

• 인덱스 설계와 최적화를 위한 기본 원리
  

이 링크에서는 인덱스와 성능 최적화 사이의 균형을 어떻게 이루어야 하는지에 대한 심층적인 논의가 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.