인덱스 고민

💡 이 글은 인덱스를 적용할 때 어떤 고민을 했는지 적은겁니다. (매우 부족합니다.) 틀릴수도 있으며 더 좋은 방법이 있을 수도 있습니다.

2장. 인덱스 - 인덱스 구조 및 탐색

2장. 인덱스 - 인덱스 구조 및 탐색

• 친절한 sql 튜닝 책을 보고 나름대로의 생각으로 적용
• 부하테스트하며 채팅 데이터가 많아 질 경우 인덱스 적용하지 않았을 경우 1 ~ 2초의 시간이 나오는 경우가 생겨 튜닝한 내용입니다.

기본적인 DB 구조

---

뭔가 많긴한데 대충 broadcast 기준으로 이것저것 있는 구조입니다.

고려했던 부분

---

1. 조회를 할 경우에 어떤 조건절을 많이 쓸까??
2. = 조건 위주로
3. broadcast_state는 ready, broadcasting, vod, end 이렇게 있는데 방송이 쌓이다 보면 vod가 압도적으로 많음(end는 soft delete 처리)

SQL

---

개발 단계에서 어느정도 완성하고 인덱스를 걸었습니다.

broadcast

analyze
select *
from broadcast broadcast0_
where (broadcast0_.broadcast_state in (2, 3))
  and broadcast0_.broadcast_start_date >= '날짜'
  and broadcast0_.broadcast_end_date <= '날짜'
  and (broadcast0_.delete_date is null)
;

analyze
select *
from broadcast broadcast0_
where (broadcast0_.broadcast_state in (2, 3))
  and broadcast0_.broadcast_start_date >= '날짜'
  and broadcast0_.broadcast_end_date <= '날짜'
  and broadcast0_.category_id = 1
  and (broadcast0_.delete_date is null)

조인 걸때도 결국 left 쪽이 필터링 되고 그 로우마다 탐색하는 과정이기 떄문에 조인이 걸려있었는데 걍 줄여봤습니다.

• broadcast_state + broadcast_start_date + broadcast_end_date
• broadcast_state + broadcast_start_date + broadcast_end_date + category

이 두가지 경우가 나온다.

analyze
select *
from broadcast
left outer join category c on broadcast.category_id = c.id
where category_id = 1

하지만 category_id를 통해서 join 하는 경우가 있어서

1. broadcast_state + broadcast_start_date + broadcast_end_date
2. category_id

analyze
select *
from broadcast broadcast0_
where store_id = 7
and broadcast_state = 1

store_id로 조회하는 부분도 있음

3. store_id + broadcast_state

⇒ 이렇게 1, 2, 3 인덱스를 뒀다. (주로 단일 조회?는 id, stream_key로 하고 리스트는 위처럼 상태, 날짜 or store_id, 상태, 날짜 이다.)

chat

---

 

analyze
select *
from chat
where broadcast_id = 1740
and chat_date <= '2023-03-27'

analyze
select *
from chat
where broadcast_id = 1740
and pid <= 5

chat을 조회할때 무조건 broasdcast_id 기준으로 걸고 chat_date, pid를 사용합니다.

1. broadcast_id + chat_date

broadcast_id + pid 인덱스를 할까 했지만 테스트 결과 옵티마이저가 broadcast_id + pid를 안잡습니다. 또한 상대적으로 콜을 적게 하기 때문에 괜찮다고 생각했다. (그래도 했어야하나? 싶습니다.. 그리고 힌트를 써야하나?)

broadcast만 인덱스 걸었을 경우

broadcast + chat_date로 인덱스 걸었을 경우

주의점

analyze
select *
from broadcast broadcast0_
where store_id = 7
and broadcast_state = 1

1. ⇒ 3번 인덱스로만 탈줄 알았는데 옵티마이저가 3, 1번을 걸어버린다. 근데 로우수는 크게 문제가 없어보이긴합니다.
2. 운영을 하고 있는데 사용자가 동시접속자 최대 1400, 누적 시청자 수 11만명이고 부하테스트도 10000 - 50000까지 해봤는데 아직 슬로우 쿼리가 나오진 않았습니다. 하지만 이용자 수가 급격하게 늘어난다면 모르겠습니다.
3. 사수가 없어 잘 한건지 모르겠습니다.