•
모임 리스트를 불러오는데, 12초가 걸린다.
◦
GET /gatherings → 이 API
응답 형태
◦
위 응답의 pageSize를 보면 3건만 가져온다.
실행되는 쿼리 형태
•
쿼리는 많이 나가지 않는 것 같은데 왜 12초나 걸릴까? 페지징도 적용 되어 있는데
•
N + 1 처럼 보이는 쿼리도 페이징 되어 있는 곳에서만? 발생한다?
◦
즉, pageSize가 3이여서 + 3만 되는 것인데 왜 이렇게 느릴까
◦
N + 1 이 맞을지 잘 모르겠다. 모임 리스트를 불러올 때 해당 글을 작성한 유저가 누구인지 파악하기 위해 모임 id를 통해 party에서 해당 유저가 누구인지 찾는다.
이 부분이 과연 N + 1 문제인가..? 조인으로 쿼리 한 방으로 풀 수 있을까?
•
이를 어떻게 해결할까 고민해보자.
1. 인덱스를 확인해보자.
실행되는 쿼리의 흐름은 유저를 먼저 찾는다. 하지만 특이하게도 유저를 token으로 먼저 찾는다.
Hibernate:
select
.
.
from
users u1_0
where
u1_0.token=?
and not(u1_0.deleted)
SQL
복사
그렇다면 token이 인덱스가 걸려있는지 확인해보자.
SHOW INDEX FROM users;
Table Key_name Column_name Cardinality
users PRIMARY id 278283
users UK2ty1xmrr nickname 234037
users UKaf44yue4 token 296103
SQL
복사
MySQL에서 UK 컬럼은 인덱스를 자동으로 생성한다. token 컬럼은 UK 제약 사항이 걸려 있다.
즉, 인덱스가 걸려 있다.
그렇다면 진짜 인덱스를 잘 타는지 실행 계획을 확인해보자.
mysql> explain select * from users where token = 'token295033';
+----+-------------+-------+-------+-----------------------------+---------+-------+------+----------+
| id | select_type | table | type | key | key_len | ref | rows | filtered |
+----+-------------+-------+-------+-----------------------------+---------+-------+------+----------+
| 1 | SIMPLE | users | const | UKaf44yue4uh61eqwe6jjyqwvla | 1022 | const | 1 | 100.00 |
+----+-------------+-------+-------+-----------------------------+---------+-------+------+----------+
1 row in set, 1 warning (0.00 sec)
SQL
복사
인덱스를 잘 타고 있다. User를 찾는 곳에서는 충분히 빠르게 동작하고 있다.
이제 다른 쿼리들을 확인해보자. (쿼리의 문제가 아닐 수 있음) → Java 메모리 내에서 페이징해서 그런가?