3000만건 데이터 select * from 주문정보 a join 주문_상품목록 b where b.주문날짜 between A and B and b.status = ? order by b.환불날짜 ASC limit 0, 10; 이유는 모르겠으나 (환불날짜) 인덱스를 타버려서 3000만건 읽으면서 100초 걸림 저기 주문 날짜가 최근꺼이거든 if 환불날짜로 정렬시엔 환불 날짜로 인덱스 타지 말게 강제해서 해결함 https://gw7193.tistory.com/m/83
Dba 에요?
ㅇㅇ - dc App
역방향 인덱스 놓으면 상관 없지 않나?
정렬을 desc로 바꾼다고? 그건 안되지 - dc App
@딘퐁 저 조건은 유지해야하는데 뜬금없이 정렬쪽 인덱스를 타서 문제인거구나
@さかいもか ㅇㅇ - dc App
@딘퐁 옵티마이저라는 게 신기하긴 하네 결국은 통계를 바탕으로 결정하니까 완벽하지 않다는 게 이번 경우에서 알 수가 있네
@さかいもか 특히 옵티마이저는 limit 관련 추정을 존나 못함 - dc App
해당 댓글은 삭제되었습니다.
단일쿼리면 괜찮은데 조건이 동적 쿼리라 다른조건인 케이스에 영향줘서 함부로 못함 - dc App
최대한 다른 케이스에 영향이 없게 해야해서 - dc App
동적쿼리라 인덱스타는듯?? 실행계획 세우고나서 변수값 바인딩되서 통계사용 잘못함 아예 못하진 않긴한데
range 후열 조건으로 equal은 못쓰니 fullscan 된거같은데 - dc App
아 필요한 인덱스는 이미 있는거구나 - dc App
개선후 0.2초 걸렸다고 하니내생각엔 status, 주문날짜 순 인덱스는 없고각각 주문날짜, 환불날짜 단일 컬럼 논클러스터드 인덱스가 있었을것이고 주문날짜 between a and b가 사용자 입장에서최근 날짜로만 조회함을 인지하지만옵티마이저에게는 파라미터에 불가함따라서 어처피 찾아가면서 10개를 만족할때탐색을 완료 해야하는데 order by 환불날짜 asc가 있으니주문날짜 인덱스 안쓰고 환불날짜 인덱스 쓴것 같음 - dc App
따라서 where 의 주문날짜 order by의 환불날짜 컬럼 치환하면 치환된대로 동일 현상 일어날꺼 같은데 - dc App
status, 주문날짜 순 인덱스는 없는거로 이해 - dc App
@30세전에특급DBA 각각 단일인덱스는 있고 아마 주문날짜 범위가 좀 넓을거임 1달인가 넓어서 날짜로 인덱스를 안잡은듯 - dc App
@30세전에특급DBA ㅇㅇ그건없음 - dc App
아 나 잘못생각했구나 - dc App
@30세전에특급DBA 그냥 주문날짜 범위 => 넓음 환불날짜 order by타면 정렬안해도되고 limit 10이라 조기종료 두개 사이에 옵티마이저가 후자를 택한듯 저긴 mysql 5.7이라 성능이 떨어지는것도 있고 - dc App
님 취준할때 리마큐 전부 읽었음? 아니면 주딱 필터링만 읽었음? 님 정도 하는 사람이면 취준때부터 다 읽었나 아니면 현업가서 빈곳 채워넣은건가 궁금함 - dc App
1권만 2번정도 본거같은데 권한 환경변수 이런건 언제든 찾아보면 되서 그냥 넘김 그외에도 전공에서 4개월 배움 - dc App
@딘퐁 중대는 학교에서 리마큐를 했노 ㅋㅋ 우린 무슨 디비수업때 이상한거 했는데 - dc App
@헤이즈넛 전공에서 리마큐를 한건 아니고 전공에서 풀스캔 인덱스구조 트랜잭션 락 등등 리마큐 기반 내용을 배움 - dc App
@딘퐁 부럽노 우린 무슨 정규화랑 sql만 주구장창 하다가 끝났는데 인덱스도 그냥 이런게 있다 이러고 ㅋㅋ - dc App
@딘퐁 일단 필터링 안타고 전체적으로 보긴 했다는거네 - dc App
실행계획 등 정보가 적지만 댓글보니까. a->b 조인. 주문날짜/상태/환불날짜 단일 인덱스 존재. 1. 주문날짜 범위 넓고 변별력 높음. 인덱스 사용 판단. 2. status NVL 낮을거라고 판단. status 인덱스만 사용하거나 주문날짜에 추가해줘도 큰 이득 못봄.
결론은 - 주문날짜로 확 줄여놓고 - status로 필터 - top n 알고리즘 작동
ㅇㅇ그냥 주문날짜이든 status든 둘중 비용낮은거로 하나로 타면 되는데 환불날짜로만 안타면 ㄱㅊ - dc App