Web Guide쿼리 최적화데이터베이스 성능색인
데이터베이스 쿼리 최적화 기초
서버를 키우기 전에 조회부터 봐야 합니다.
느린 사이트의 상당수는 데이터베이스 조회 한두 개가 원인입니다.
01발주자가 알아야 할 것
직접 고칠 수는 없지만 무엇이 문제인지 이해하면 제작사와 소통이 됩니다.
1
색인
찾을 때 쓰는 목차 같은 것입니다. 없으면 전체를 훑습니다.
2
반복 조회
목록 항목마다 추가 조회가 일어나는 구조가 흔한 문제입니다.
3
불필요한 항목
쓰지 않는 큰 데이터까지 가져옵니다.
4
정렬
준비 없이 정렬하면 매우 느려집니다.
5
전체 검색
내용 안을 뒤지는 검색은 특히 무겁습니다.
02색인이 만능은 아니다
색인을 많이 만들면 조회는 빨라지지만 저장은 느려집니다. 균형이 필요합니다.
색인의 장점
조회가 빨라짐 · 정렬이 빨라짐 · 대량 데이터에서 효과가 큼
색인의 비용
저장과 수정이 느려짐 · 디스크 용량 증가 · 과하면 오히려 손해 · 실제로 쓰이는지 확인 필요
03찾는 방법
감으로 고치지 말고 실제로 느린 것을 찾아야 합니다.
느린 조회 기록일정 시간 이상 걸린 조회를 기록하게 설정합니다.
실행 계획 확인조회가 어떻게 처리되는지 확인합니다.
실제 데이터로적은 데이터로 테스트하면 문제가 안 보입니다.
반복 호출 확인한 화면에서 몇 번 조회하는지 셉니다.
정기 점검데이터가 늘면 새로운 문제가 생깁니다.
04구조적 개선
조회를 고치는 것으로 부족하면 구조를 바꿔야 할 수도 있습니다.
집계 테이블 통계용 데이터를 미리 계산해 따로 저장합니다.
데이터 분리 오래된 데이터를 별도로 옮깁니다.
읽기 분산 조회 전용 서버를 두어 부담을 나눕니다.
검색 도구 분리 검색은 전용 도구로 옮깁니다.
구조 재설계 설계 자체가 문제면 근본적인 조정이 필요합니다.
CHECK POINT
□ 느린 조회를 기록하고 있는가
□ 실제 규모의 데이터로 테스트했는가
□ 자주 쓰는 조회 조건에 색인이 있는가
□ 한 화면의 조회 횟수를 확인했는가
□ 쓰지 않는 색인을 정리했는가
□ 통계 조회를 미리 집계하고 있는가
□ 데이터 증가에 따라 정기 점검하는가
#쿼리 최적화#데이터베이스 성능#색인#느린 조회#집계#서버 부하#성능 개선#홈페이지 개발#웹비스타#홈페이지 제작