[조회 성능 개선하기] 에어(김준서) 미션 제출합니다. #13
Conversation
| 추가적으로 `전체 프로그래머 수를 구하기 위한 서브쿼리`는 hobby 인덱스가 아닌 클러스터링 인덱스를 사용하면 검색이 빠를 것이라 생각하여 `programmer` 테이블의 id에 pk와 unique를 걸어줬습니다. | ||
| ```sql | ||
| ALTER TABLE `subway`.`programmer` | ||
| CHANGE COLUMN `id` `id` BIGINT(20) NOT NULL, | ||
| ADD PRIMARY KEY (`id`), | ||
| ADD UNIQUE INDEX `id_UNIQUE` (`id` ASC); | ||
| ``` |
There was a problem hiding this comment.
우선 에어가 해준 질문에 대해 이것 저것 실험해본 결과를 여기에 정리해보면,
영향이 미치는 rows의 수와 query cost가 변하는 시점은 unique 키 없이, programmer의 id에 pk만 걸어주더라도 에어가 보여주신 것처럼 쿼리코스트는 증가하되, 실제 수행시간은 더 줄어들더라구요.
왜 그렇게 되는지는 저도 모르겠네요 ㅠ 저도 쿼리 코스트가 실제 수행시간에 영향을 미치는 것이라 생각했었거든요.
아무튼 이 경우에 저는
- PK를 거는 시점에 UK를 걸 필요가 없다는 점.
- 실제로 실행해봤을 때 큰 차이가 없다는 점.
이러한 이유로 hobby와 PK만 걸어줄 것 같습니다.
There was a problem hiding this comment.
오 primary만 걸어도 성능은 비슷한가보네요 감사합니다!
| SELECT | ||
| c.programmer_id, hospital.name AS hospital_name | ||
| FROM | ||
| (SELECT hospital_id, programmer_id FROM covid) AS c | ||
| JOIN hospital | ||
| ON hospital.id = c.hospital_id | ||
| JOIN (SELECT id FROM programmer) AS p | ||
| ON p.id = c.programmer_id |
There was a problem hiding this comment.
covid에 이미 programmer_id 컬럼이 있기 때문에 programmer 테이블은 굳이 조인을 안해줘도 될것 같아요 🙂
There was a problem hiding this comment.
programmer 테이블을 조인해주지 않으면 covid의 programmer_id가 null인 필드 까지 모두 나오더라구요 ㅠㅠ
그래서 covid의 programmer_id가 실제로 존재하는 항목만 가져오게 하려고 join을 사용했어요!
There was a problem hiding this comment.
아 이런 부분 때문에 조인을 한번 더 걸어주셨군요..!
제가 수정해야겠네요 이건 😅
| 추가적으로 실행계획을 보면 `member`의 filtered가 비효율적인 것을 볼 수 있습니다. `member`에서는 age에 BETWEEN 구문을 쓰고 있기 때문에 age에 인덱스를 걸어 정렬되도록 하였습니다. | ||
| ```sql | ||
| CREATE INDEX `idx_member_age` ON `subway`.`member` (age); | ||
| ``` |
There was a problem hiding this comment.
오 like 문을 쓰면 like 2% 과 같이 %가 뒤에 오더라도 인덱스를 타지 않는군요!
배워갑니다 👍
There was a problem hiding this comment.
어느 부분 말씀을 하신 걸까요~?? 혹시 아래 join문을 말씀하시는 걸까요??
JOIN (SELECT id FROM programmer WHERE (hobby = 'Yes' AND student LIKE 'Yes%') OR years_coding = '0-2 years') AS p
저는 like 2%와 같이 %가 뒤에 오는 경우는 인덱스를 사용할 수 있는 걸로 알고 있어요! 다만 OR이 사용되면 인덱스를 사용하지 못하는 것으로 알고있어요!
혹시 제가 잘못알고 있는 부분이 있다면 알려주시면 감사하겠습니다~🙏
There was a problem hiding this comment.
에어 말처럼 like문을 사용해도 index를 타기는 하네요! 그런데 아래와 같이 filtered와 쿼리코스트에서 차이가 나네요.
- like를 사용하는 경우 :
filtered = 11,쿼리코스트 = 27874 - between을 사용하는 경우 :
filtered = 44.17,쿼리코스트 = 29056
왜 이런 결과가 나올까 이것저것 해본 결과
- like를 사용할 시 indexFullScan, filter = 11
- between을 사용할 시 indexRangeScan, filter = 100
을 사용한다는 것까지 발견했어요. 그래서 원래 미션 쿼리에서 filtered와 쿼리코스트에 영향을 미치는 것이 이 부분때문인가? 싶었고요.
그런데 문제는 아래와 같은 간단한 조인문에서는 배운대로 rangeScan을 하는 경우 rows도 쿼리코스트도 더 적게 나오는 것을 확인한 반면, 미션 쿼리에서는 오히려 쿼리코스트가 증가했다는 것이죠...
열심히 이것저것 해봤지만 이 부분에 대한 답은 얻지 못했네요 😭
혹시 아시는 부분이 있다면 저에게도 한 말씀 부탁드립니다..ㅎㅎ
|
제가 approve만 하고 깜빡하고 머지를 안했네요..? 죄송합니다... 남겨주신 코멘트에 답글 몇가지 남겼으니 나중에 확인해주시면 감사하겠습니다 🙇♂️ |
안녕하세요 아론 Hi Hi 오랜만이네요 잘 지내시나요??
이번 미션은 생소해서 많이 어려웠어요 😭
감이 올랑말랑 하는데, 잘 모르겠네요 ㅎㅎ.. 특히 서브쿼리의 WHERE절과 JOIN에서 해당 테이블이 사용될 때 인덱스를 어떻게 걸어야할지 잘 모르겠습니다ㅎㅎ.. 실행 계획을 보고 먼저 실행되는 테이블과 관련된 조건부터 인덱스를 거는식으로 시도해봤는데 솔직히 애매모호 하네요
😭😭
리뷰 잘 부탁드립니다~~🙏🙏🙏
편하게 보기!
B1번 문제를 진행하면서 궁금한게 하나 생겼어요.
programmer의 id에 pk, unique를 걸어주니 unique 인덱스를 이용하고 속도가 빨라졌어요. 그런데 Query cost는 증가하더라고요.
[걸어주기 전]
[걸어준 후]
Query cost가 작을수록 더 빠른 것이라고 생각하고 있었는데 cost와 실행시간은 상관이 없는 지표일까요?
cost가 중요할지 실행시간이 중요할지도 잘 모르겠네요. 아론은 뭐가 더 중요하다고 생각하시나요? 아론의 의견이 궁금하네요.
Q. unique 인덱스를 쓰든지 unique가 아닌 인덱스를 쓰던지 Full Index Scan시 탐색 row 수는 동일한 것 같은데, 왜 unique 인덱스를 사용하면 더 빨라질까요?? 혹시 아신다면 알려주시면 정말 감사할 것 같습니다 ㅎㅎ..