[일반] (ㅇㅎㅁ정답)초고난이도 쿼리 튜닝 SQL 문제 올려요

[딘퐁(film1341)]

https://gw7193.tistory.com/m/99

[밀우(ggbadza2)]

2번은 월단위로 범위파티셔닝하고 합계금액,id 기준 로컬인덱스 걸면 되나? 파티셔닝은 쓰면안되는건가

[딘퐁(film1341)]

파티셔닝은 1/12배 성능 개선될 수 있지만 근본적인 해결은 안될거같아요 2번 인덱스 추가가 (sum_price, id)라면 오답입니다. - dc App

[밀우(ggbadza2)]

@딘퐁 파티셔닝하면 조건절은 파티셔닝 조회시에만 쓰고 데이터받아오는건 인덱스로 sorting연산 생략 되잖엉 범위조건은 그냥 파티션 조회할때만 들어갈거고 실제정렬을 수행하진 않으니 1/12 성능향상보다 많이 향상될거같은데

[딘퐁(film1341)]

@밀우 쿼리 하나 때문에 물리구조를 바꾸는건 오버엔지니어링 이예요 - dc App

[밀우(ggbadza2)]

[딘퐁(film1341)]

@밀우 파티셔닝으로 인해 파급되는 영향력이 너무 커서 해당 방법은 제외하겠습니다. - dc App

[딘퐁(film1341)]

@밀우 1번은 오라클에 적용이 안되는 방법입니다 2번은 오라클도 가능할거같네요 - dc App

[밀우(ggbadza2)]

@딘퐁 그렇다면 주문년월 칼럼을 추가헤서 주문년월+합계금액+id 인덱스추가하기

[딘퐁(film1341)]

@밀우 무조건 3월이 아니라 3.14~5.12등 주문 범위는 유동적입니다 - dc App

[딘퐁(film1341)]

@밀우 (sum_price, id) 인덱스를 추가해도 인덱스를 안탑니다 - dc App

[백갤러 1(210.219)]

1번에 새로 인덱스 추가 안하고 기존 인덱스중에서 sum_price 같이 정렬 타게해고 기간 range 범위조건 맞는지 체크해서 limit만큼만 보고 끝내기

[딘퐁(film1341)]

2차 정렬 id때문에 sum_price 정렬을 못타요 - dc App

[백갤러 1(210.219)]

@딘퐁 그러면 ㄹㅇ 서브쿼리로 3월 범위만 따로 떼어놓고 후처리 정렬하는거 말곤 생각안나는데

[백갤러 1(210.219)]

@딘퐁 엥 뭐야 내가 말한것도 밑에랑 같은건데 asc 정렬 타야한다며

[딘퐁(film1341)]

@백갤러1(210.219) 내가 이해를 못했음 기존 인덱스중에서 sum_price 같이 정렬타게 하고가 무슨 방법 말하는지 이해를 못함 - dc App

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[딘퐁(film1341)]

@ㅇㅎㅁ 축하드려요 1번에 대한 정답입니다. - dc App

[딘퐁(film1341)]

@ㅇㅎㅁ 2번은 (sum_price , id desc) 혹은 (sum_price desc, id) 맞습니다 correct - dc App

[백갤러 2(116.45)]

재밌다