인프런 커뮤니티 질문&답변
작성한 질문수
인덱스 분할, 병합에 따른 인덱스 적용 기준과 OPTIMIZE TABLE
작성
·
17
·
수정됨
0
hong님 안녕하세요!
인덱스 분할, 병합 내용을 보면서 단순하게 인덱스를 걸면 안되겠다는 생각이 들었습니다.
질문1
인덱스 분할, 병합 관점에서 인덱스를 걸어도 괜찮다는 결론에 도달할때 과정이 궁금합니다!
인덱스로 인해 줄어드는 조회 비용 > 인덱스로 인해 증가하는 쓰기 비용을 정량적으로 계산해서 적용하시나요?
ex) 쓰기 패턴 및 TPS 조사, redo log 증가량 확인, 인덱스 개수, 테이블 크기 등
질문2
라이브 환경에서 OPTIMIZE TABLE 실행해도 문제가 없을까요? 느낌상 최후의 수단으로 실행 해야하나 생각이 들었는데요. 고려해야할 사항이 있는지 궁금합니다!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. soap님.
인덱스의 분할 및 병합을 고려할 때, 인덱스 적용의 기준은 데이터베이스 성능 최적화의 핵심 요소 중 하나입니다. 인덱스는 읽기 성능을 크게 향상시키지만, 잘못 설계된 인덱스는 쓰기 성능에 영향을 줄 수 있습니다. 따라서, 인덱스를 설정할 때 다음과 같은 요소를 고려합니다.
인덱스 설정 시 고려사항
읽기/쓰기 비용의 균형:
- 읽기 비용: 인덱스를 추가하면 데이터를 조회하는 속도가 빨라집니다. 하지만 각 쿼리의 실행 계획을 상세히 검토하여 인덱스가 얼마나 효율적인지 확인해야 합니다.
- 쓰기 비용: 인덱스가 많아질수록 삽입, 갱신, 삭제 시 더 많은 비용이 발생합니다. 이는 인덱스 업데이트를 위한 부가 작업 때문입니다.
- 읽기 비용: 인덱스를 추가하면 데이터를 조회하는 속도가 빨라집니다. 하지만 각 쿼리의 실행 계획을 상세히 검토하여 인덱스가 얼마나 효율적인지 확인해야 합니다.
TPS(Transactions Per Second)와 패턴 분석:
- 주로 읽기와 쓰기 패턴을 분석하여 인덱스가 필요한지 결정합니다. 예를 들어, 읽기 작업이 빈번하고 TPS가 높은 시스템에서는 읽기 성능을 우선시하는 인덱스 설계가 필요할 수 있습니다.
- 주로 읽기와 쓰기 패턴을 분석하여 인덱스가 필요한지 결정합니다. 예를 들어, 읽기 작업이 빈번하고 TPS가 높은 시스템에서는 읽기 성능을 우선시하는 인덱스 설계가 필요할 수 있습니다.
Redo Log 및 디스크 사용량:
- 인덱스가 추가되면 redo log 크기가 증가할 수 있습니다. 이는 DB 복구에 영향을 미칠 수 있으므로, I/O 대기 시간과도 관련됩니다. 따라서, 시스템의 I/O 성능에 따라 인덱스의 영향을 측정해보는 것이 좋습니다.
- 인덱스가 추가되면 redo log 크기가 증가할 수 있습니다. 이는 DB 복구에 영향을 미칠 수 있으므로, I/O 대기 시간과도 관련됩니다. 따라서, 시스템의 I/O 성능에 따라 인덱스의 영향을 측정해보는 것이 좋습니다.
테이블 및 인덱스 크기:
- 인덱스가 커질수록 메모리 자원을 더 많이 소모합니다. 만약 인덱스 크기가 메모리 한도를 초과한다면, 쿼리 성능이 저하될 수 있습니다. 이러한 경우에는 인덱스를 효율적으로 작게 유지할 필요가 있습니다.
- 인덱스가 커질수록 메모리 자원을 더 많이 소모합니다. 만약 인덱스 크기가 메모리 한도를 초과한다면, 쿼리 성능이 저하될 수 있습니다. 이러한 경우에는 인덱스를 효율적으로 작게 유지할 필요가 있습니다.
정량적인 측면에서는 위 요소들을 모니터링하고, 인덱스 추가 전후의 성능 차이를 벤치마크하는 방법을 사용할 수 있습니다.
아래 링크를 통해 인덱스 최적화와 관련된 더 많은 정보를 얻으실 수 있습니다:
이 링크에서는 인덱스와 성능 최적화 사이의 균형을 어떻게 이루어야 하는지에 대한 심층적인 논의가 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.