DB 느릴 때 편집하기

==개요==
;DB 느릴 때 
;RDB 느릴 때

{| class='wikitable'
! 항목 !! 애플리케이션 변경 !! 인프라 구성 변경
|-
|
;1. 느린 쿼리 및 DB 테이블 확인 ★★★
* 가능한 경우, 실행계획까지 확인하면 더욱 좋다. (쿼리 내부에서 어디가 병목인지 확인)
* 쓰기가 느린가? 읽기가 느린가?
* 인덱스(PK, UNIQUE, INDEX)가 적절히 설정되었는가?
* JOIN 관계는 적절한가?
** 불필요하게 많은 테이블을 JOIN하고 있지는 않은가?
** FULL JOIN을 LEFT JOIN으로 바꿔볼 수는 없는가?
* 너무 많은 컬럼/행
** 테이블에 너무 많은 컬럼이 있는 것은 아닌가?
** 너무 많은 컬럼을 SELECT 하고 있는 것은 아닌가?
** 너무 많은 행을 가진 테이블은 없는가?
** 여러 테이블/DB로 분산해보면 어떨까? 예: [[샤딩]]
** 자주 조회되는 간단한 요약 정보가 있다면 요약 테이블을 따로 만들어보면 어떨까?
* 게으른 처리
** 실시간 갱신이 필요한 것이 아니라면, 다른 곳에 쌓아놨다가 야간(어쨌든 바쁘지 않은 시간)에 처리할 수는 없을까?
* N+1 문제?
** 혹시 ORM을 사용한다면 N+1 문제가 없는지 살펴보자.
| 3️⃣
| 0️⃣
|-
|
;2. DB 상태 확인 및 튜닝
* DB 상태를 확인하고 설정(DB 파라미터)이 적절한지 검토한다.
* 적절한 크기의 DB 캐시 설정은 매우 중요하다. 
* OS의 메모리 크기와, DB에 할당한 메모리의 크기, DB 캐시의 크기는 적절한가?
* 필요시 advisory 도구를 활용해볼 수도 있다.
| 0️⃣
| 0️⃣
|-
|
;3. DB 구성 확인 및 개선
* 수평 확장 - 1대라면 Replication이나 Clustering 구성으로 2~3대로 늘려보면 어떨까?
* 수직 확장 - CPU나 메모리 사용률이 높다면 해당 리소스를 높여보면 어떨까?
| 수평 확장(1️⃣~2️⃣)<br>수직 확장 0️⃣
| 수평 확장(3️⃣)<br>수직 확장 0️⃣
|-
|
;4. DB 캐시 구성
*  Redis/Memcached 등으로 캐시를 적용해보면 어떨까?
| 1️⃣~2️⃣
| 1️⃣
|-
|
;5. 기타
* 어쨌거나 앞단에서 DB Hit를 줄일 수 없는가?
* DB 내용 중 일부를 다른 DB, object storage로 분산
* webcache 도입
:애플리케이션 특성에 따라 DB Hit 줄이는 효과가 별로 없을 수도 있다.
* 다른 DB 추가 도입
** 특정 컬럼에 매우 긴 글(text)가 있고, 부분문자열 검색(LIKE %%)을 자주 하는 경우하는 경우 → 해당 테이블을 Elasticsearch에 복제하여 검색하는 방법 검토
| 1️⃣
| 2️⃣
|}

==같이 보기==
* [[웹 느릴 때]]

[[분류: DB]]