결론
•
기존에 걸려있는 인덱스 외(FK)에 다른 인덱스를 걸지 않기로 결정
•
ORDER BY는 인덱스 대신 filesort를 통해 정렬하는 것으로 결정
•
comment테이블은 insert query 사용량도 고려해야 하기 때문에
1. findAllByOfferingOrderByCreatedAt
Hibernate:
select
ce1_0.id,
ce1_0.content,
ce1_0.created_at,
ce1_0.member_id,
ce1_0.offering_id,
ce1_0.updated_at
from
comment ce1_0
where
ce1_0.offering_id=?
order by
ce1_0.created_at
SQL
복사
인덱스가 없을 때(기본 fk 인덱스만 설정)
created_at 칼럼에 인덱스를 적용해야 할까?
•
Extra를 보면 filesort를 통해 정렬을 진행한다.
•
comment 테이블의 최대 레코드 크기 : 280 byte
•
sort_buffer_size = 256kb = 262144 byte
•
sort_buffer_size 내부에서 최대로 정렬할 수 있는 레코드의 수 = 약 936건
→ 각 Offering 당 comment는 1천 건 미만으로 다수 생성될 것으로 예상됨, 인덱스를 설정하는 것보다 현행대로 filesort를 사용하는 것이 좋다고 판단
+) 현재 findAll 쿼리를 사용 중인데, 추후 쿼리를 좀 더 최적화하여 개선한다면 인덱스를 설정하지 않아도 될 것이라 예상됨
2. findTopByOfferingOrderByCreatedAtDesc
Hibernate:
select
ce1_0.id,
ce1_0.content,
ce1_0.created_at,
ce1_0.member_id,
ce1_0.offering_id,
ce1_0.updated_at
from
comment ce1_0
where
ce1_0.offering_id=?
order by
ce1_0.created_at desc
fetch
first ? rows only
SQL
복사
인덱스가 없을 때(기본 fk 인덱스만 설정)
findAllByOfferingOrderByCreatedAt쿼리와 같다. 추가된 부분은 hibernate에 의해 fetch 절이 추가된 점, 정렬이 desc로 설정된 점이라 findAllByOfferingOrderByCreatedAt 와 마찬가지로 인덱스를 추가하지 않아도 될 것이라 판단한다.