[refactor] findTopByUserIdOrderByCreateDateDesc 쿼리 성능 개선

[RumosZin]

연관 이슈

• [refactor] findTopByUserIdOrderByCreateDateDesc 쿼리 성능 개선 #49

작업 내용

findTopByUserIdOrderByCreateDateDesc로 인한 조회 성능에 문제가 없는지 dummy data를 넣어 테스트했습니다. select * from photo_request where user_id=? order by create_date desc limit 1;에 대해 user를 1000명 생성하고, user마다 100번 요청을 생성했다고 (다소 극단적으로) 가정하고 진행했습니다.

user_id 단일 칼럼 인덱스

조회 시 Using filesort가 발생합니다. user_id 1000으로 위 select 쿼리를 실행했을 때 100개의 요청을 가져오고, MySQL 내부에서 100개 요청을 정렬합니다.

(user_id A, create_date A) 다중 칼럼 인덱스

조회 시 Backward index scan이 발생합니다. select 쿼리에서는 order by create_date DESC로 내림차순 정렬 결과를 원하는데 인덱스는 ASC로 오름차순 정렬되어 있어서 발생합니다. 관련해서 MySQL Ascending index vs Descending index 글을 참고했는데 읽어보시면 도움 될 것 같아요!

(user_id A, create_date D) 다중 칼럼 인덱스

쿼리에서 요구하는대로 인덱스의 오름차순, 내림차순 정렬이 되어있기 때문에 인덱스가 목적대로 동작합니다.

결론?

결론적으로 (user_id A, create_date D) 다중 칼럼 인덱스를 사용하면 정확히 findTopByUserIdOrderByCreateDateDesc에 대한 조회 쿼리 성능 향상에 도움이 될 수 있지만, 다음과 같은 이유로 인덱스를 적용하지 않는 것이 좋을 것 같아요!

1. 우리 서비스는 한 사람의 조회보다 여러 사람의 요청이 더 많이 발생하기 때문에 insert 성능을 포기할 수 없다.
2. 현재 Using filesort가 발생하는 것이 나쁜 선택지가 아니다. user_id는 외래키로서 이미 인덱스로 관리되고 있기 때문에, user_id로 검색해서 나오는 데이터 (많아봐야) 5개에 대한 MySQL 메모리 상의 정렬은 쿼리 성능을 지나치게 저해하지 않는다.

참고 자료

PR에 모든 과정과 결과를 담기에 무리가 있어 작업 내용에는 간단히 실험 결과, 결론만 작성했습니다. 각 케이스에 대한 자세한 내용은 조회 성능을 위해 WHERE / ORDER BY 조건을 다중 칼럼 인덱스로 설정해도 될까? 이곳에서 확인할 수 있습니다.

리뷰 요구사항

코드 간단히 살펴봤는데, user_id로 where절 조건이 들어가는데 인터페이스에는 이름이 requestId로 적용되어 있어서 변경했습니다!

[win-luck]

자잘한 이슈가 있었네요 감사합니다~!

[alsrudrl1220]

수고 많으셨습니다! 깊게 고민한 흔적이 느껴지네용
생각해보지 못한 부분이었는데, 좋은 주제인 것 같습니다~

말씀해주신 것처럼 한 사람에 대한 조회 결과가 많지 않기 때문에 여기에 적용하진 못하겠지만
나중에 비슷한 다른 상황에서 적용해볼 수 있을 것 같아요.

새롭게 배워갑니다:)

[tthisag246]

수고 많으셨습니다!

이렇게 자세히는 생각해 보지 못했는데, 덕분에 성능 개선에 대해 깊이 고민해 볼 수 있었던 것 같습니다.

문제를 제기하고 실험하는 과정도 새롭게 배울 수 있었고, 자세한 설명 덕분에 "trade off를 고려하여 기존 방식을 유지한다"는 결론에도 자연스레 동의하게 되었습니다.

좋은 글 감사합니다👍