[조회 성능 개선하기] 다니(이다은) 미션 제출합니다. #27
Conversation
There was a problem hiding this comment.
안녕하세요 다니!
전반적으로 깔끔한 문서화로 피드백하기 정말 편했어요 ㅎㅎㅎ
질문에 대한 답변은 각각 코멘트를 달았어요
의문점
hospital을 varchar로 바꾸고, unique를 걸어야할 이유가 있을까?
기존에 있던 타입을 하나의 쿼리 요구사항으로 인해 바꾸는게 괜찮은 접근 방식일까요?!
저도 처음 변경했다가, 굳이 unique재약 조건을 걸지 않아도 원하는 시간안에 해결할 수 있어, 다시 원래대로 돌렸었거든요!! 다니의 생각이 궁금해요 :)
또한, 병원이름이 중복될 수 있을거 같기도해요 ㅎㅎ
테이블 join시, 필요한 row만 가져올 수 있지 않을까?
[ ] 프로그래밍이 취미인 학생 혹은 주니어(0-2년)들이 다닌 병원 이름을 반환하고 user.id 기준으로 정렬한다.
[ ]서울대병원에 다닌 30대 환자들을 운동 횟수별로 집계한다.
이 2개의 미션에서, 전체 join이 완료된 후 where 절로 필요 row를 가져오고 있어요!
join을 할때 필요한 row를 해당 테이블에서 가져오면 조금더 성능향상을 이룰 수 있을거 같아요 ㅎㅎ
결론
전반적으로 쿼리 작성을 잘해주셔서, 단순한 피드백을 남겼어요 ㅎㅎㅎ 역시 다니 짱짱 😊
| #### 1. | ||
| 문제에서 "~ `최근에` 각 지역별로 언제 퇴실했는지 조회한다."라고 돼있는데요.<br/> | ||
| 이 뜻은 입출입시간을 기준으로 내림차순 정렬하라는 걸까요?<br/> | ||
| 현재는 이렇게 작성되어 있는데, 검프의 생각이 궁금합니다!<br/> |
There was a problem hiding this comment.
네, 저도 "~최근에"라는 말을 통해 높은연봉의 사원과, 입출입시간 두 개를 내림차순 정렬 했어요
문제 의도를 잘 파악하셨네요!! :)
| 테이블은 아래처럼 출력됐어요.<br/> | ||
| 정답에 있는 입출입시간 값(e.g. 2020-09-06)이 아예 없었습니다.<br/> | ||
| 저만 그런가 싶어 몇몇 크루들한테 물어봤는데, 저와 같은 경우도 있고 아닌 경우도 있더라구요 😵💫<br/> | ||
| 검프는 결과가 똑같이 나오나요??<br/> | ||
|
|
There was a problem hiding this comment.
저도 데이터가 없어서 제외하고 미션을 진행 했어요
SELECT * FROM 사원출입기록 WHERE 사원번호 = 110039 ORDER BY 입출입시간 desc;위와 같이 쿼리를 작성해도 다니와 같은 결과가 나오네요 😊
테이블 자체에 데이터가 없는 거 같은데.. 데이터가 있던 크루들은 어떻게 했을까요 🤔 신기하네요
| 그래서 Full Table Scan을 해결하려 (사원번호)로 인덱스를 걸었는데요.<br/> | ||
| 그리고 실행 시간을 확인하니 67-70ms 정도는 나오는데, 50ms 이하로는 안 나오더라구요 🥲<br/> | ||
| 다른 곳도 개선할 수 있는 부분이 있을까 싶어 여기저기 찾아보고 인덱스를 걸어봤는데요.<br/> | ||
| 오히려 실행 시간이 늘어나는 경우도 있고, 딱히 나아지지 않았습니다 😂<br/> | ||
| 검프는 어디에 인덱스를 추가해줬나요? 혹시 제가 놓친 게 있을까요??<br/> |
There was a problem hiding this comment.
다니의 쿼리를 실행해봤을 때, 제 컴퓨터(Macboot Pro 20 32GB ram)에서는
2,2ms 대의 속도가 나오네요!
저는
CREATE INDEX `idx_사원_입출입구분_사원` ON `tuning`.`사원출입기록` (사원번호,입출입구분);와 같이 인덱스를 설정했어요. (지금보니, 입출입 구분와 같이 복합 인덱스를 구성하는 것이 딱히 의미가 없네요 :), 다니가 걸어주신 인덱스가 더 좋은 인덱싱이라 생각해요)
다니가 작성하신 쿼리도 요구사항을 만족했고, 충분히 빠른 쿼리이기 때문에( 다니 컴퓨터에서 한다고 해도 7mss)
문제가 없다고 판단됩니다
There was a problem hiding this comment.
와.. 0.0070sec이면 7ms인데, 이걸 70ms라고 잘못 계산했네요.. 😅
허허 요구사항을 만족하는 쿼리였네요 ㅎㅎㅎㅎㅎㅎㅎ
| 커버링 인덱스로 성능을 개선시키는 건 이해했는데, PK를 지정했을 때 성능이 더 개선되는 이유가 궁금합니다.<br/> | ||
| 실행 계획을 보면, PK를 추가했을 때 읽는 레코드 양도 늘어나는데 말이죠 🤔<br/> | ||
| 검프는 왜 이런지 알고 있나요??<br/> |
There was a problem hiding this comment.
좋은 질문이네요!!
우선 다니가 진행하신 플로우대로 진행해봤지만, programmer에서 PK를 추가하는 과정에 성능 추가를 확인하지 못했어요.
우선 prgrammer에 pk를 걸기 전, 인덱스 페이지를 얼마나 읽어 들이는지 확인해봤어요
show global status like 'Innodb_pages_read';
(다니 쿼리 실행)
show global status like 'Innodb_pages_read';
인덱싱을 걸고난 후
show global status like 'Innodb_pages_read';
(다니 쿼리 실행)
show global status like 'Innodb_pages_read';
쿼리실행 전 후로 페이지의 수가 차이가 없네요, 아무래도 Index Range Scan을 해서, 리프 페이지 까지 도달하지 않아 그런 것 같아요.
하지만, 인덱싱 설정 전 후로 읽어들이는 페이지가 커지는 것을 봐서 programmer에 pk를 거는 것이 오히려 효율이 더 안좋다고 생각들 것 같아요.
(clusterd index + non-clusterd index가 구성되며, 페이지 수가 더늘어남)
결국, 실제로 최적화가 일어나지 않았다고 보이는데.. 혹시 다시 한번 확인해주실 수 있을까요?!
There was a problem hiding this comment.
앗 검프가 확인했을 때는 큰 성능 변화가 없었나요?!
기존의 인덱스를 전부 삭제하고, 다시 쿼리를 실행해봤어요 !
PK 추가 전
실행 시간
실행 계획
- 73393개의 행 조회
- 717ms 소요
PK 추가 후
실행 시간
실행 계획
- 74465개의 행 조회
- 473ms 소요
앞선 결과로 PK를 거는 것도 성능 최적화 방법 중 하나라고 생각했어요.
한편 탐색하는 행은 약 400개가 늘었는데 실행 시간은 약 240ms 줄어서, 그 이유가 궁금했어요 !
그런데 검프가 봤을 때는 별로 성능 개선이 없다고 하니까..!
실제로 최적화가 일어나는 게 아닌 걸까요? 🤔
There was a problem hiding this comment.
제 컴퓨터 기준에서 말씀드린겁니다!!
clusterd index + non-clusterd index 구성으로 인해 분명 리프 페이지수가 늘어났을텐데.. 왜 더 빨리지지?!
아마 제 생각엔... pk를 설정함으로써 정렬이 되어 성능 향상이 일어난거 같네요. . :) (저도 신기하네요..)
There was a problem hiding this comment.
오오 PK 추가로 정렬이 돼서 성능 향상이 일어난 게 맞는 것 같아요!
함께 고민해줘서 감사합니다 ㅎㅎㅎㅎ 👍
| <details> | ||
| <summary>질문</summary> | ||
| <br/> | ||
|
|
||
| 커버링 인덱스가 적용되고 있는데도 Full Table Scan을 하는 이유는 무엇일까요??<br/> | ||
| 커버링 인덱스는 인덱스만으로도 결과를 도출할 수 있어 디스크까지 접근하지 않는다고 이해하고 있는데, 제가 놓친 부분이 있을까요?<br/> |
There was a problem hiding this comment.
커버링 인덱스가 적용되었지만, covid에 programmer_id가 null인 칼럼이 20만건 가량 되더라고요.
그렇기 때문에, covid에선 full index scan을 진행한게 아닐까 싶어요. (일정 row를 가져오는게 10100만일때 520%의 손익 분기점이 생기는데, 이 분기점을 넘게되면 옵티마이저가 판단해서 알아서 full scan으로 변경하는 것으로 알고있어요. )
|
검프 ~~! 꼼꼼한 피드백 감사합니다 ㅎㅎㅎ 요즘 많이 바쁘겠지만 ㅠㅠ |
검프 하이하이 🙌
레벨 1에는 페어로 보고, 이번에는 리뷰어/리뷰이로 만나니까 더 반갑네요 ㅎㅎㅎ
인덱스 지식이 부족해서 공부하며 진행했어요!
그래서 제출이 조금 늦었네요 🥲
그래도 쿼리 튜닝을 어떻게 해야 하는지 등 새로 배운 게 많아서 넘 뿌듯해요 ~!
성능을 개선하려 열심히 노력해봤으니까 가감 없는 피드백 부탁드립니다 !
날씨가 갑자기 겨울이 됐는데, 감기 조심하세요!! 😷
바쁜 와중에 시간 내주셔서 고맙습니다 🙇♀️✨
편하게 읽기