[일반] DB 똥글

[돌솥굴국밥(wldyd4195)]

옵티마이저 좀 어려운듯..

락이랑 인덱스는 순항했는데

임시테이블 이용한 정렬 파트에서 진도가 좀 더디다..

블로그 카더라 말론 대규모 서비스 시 주요 병목 지점이라는 둥 좀 중요해 보이는 파트같은데..

일단 실행계획 봣을때 using temporary; 떠있으면 줄여야 된다는건 이해햇다..

- dc official App

[백갤러 1(118.235)]

ㅎㅇ 롤하다옴 옵티마이저는 인덱스 통계를 기반으로 하여금 조인조건, where조건 입력값에 따라 최적화된 쿼리플랜을 생성하는 내부프로그램임 대규모서비스에서 해당 프로그램과 관련해서 이슈가 발생하는것은 데이터 스큐에 의한 변질된 인덱스 통계로 파라미터 스니핑을 통한 잘못된 쿼리플랜을 생성하기때문 - dc App

[백갤러 1(118.235)]

간단한 예를 들어서 어떤 속성의 도메인의 범위가 2인데각각의 값에 대한 레코드 량의 편차가 존나게 클때레코드가 많은 값을 조건으로 줬을때는 스캔연산이레코드가 적은 값을 조건으로 줬을때는 싴 연산이유리한 경우로 나뉘는데해당 쿼리에대한 쿼리플랜이 메모리에 캐싱되기전첫 쿼리에 대한 파라미터로 레코드가 많은 값으로 조건이 들어왔을때 해당 파라미터값을 기준으로쿼리플랜을 스캔연산자로 사용하도록 작성하여다른 값의 조건이 들어왔을때도 스캔하게되어비효율적인 쿼리플랜이 발생되는것임 - dc App

[백갤러 1(118.235)]

이를 방지하기 위한 수단으로 - 매번 쿼리플랜을 새로 컴파일하도록하는 옵션을 사용 - 데이터스큐를 식별하여 두가지쿼리로 분기하도록 작성 - rdbms에서 지원하는 보조 기능을 사용 (mssql의 경우 adaptive join, 쿼리 저장소, 또뭐였더라 여튼 등등) 이 있으나 1번 3번은 별도의 추가 작업없이 자동으로 처리된다는 장점이있으나 cpu나 메모리 리소스 사용량이 증가함 보통의 DBA는 데이터 스큐를 인지하고 쿼리를 분기하는 방식으로 해당 문제를 처리함 - dc App

[백갤러 1(118.235)]

추가적으로 데이터 스큐와 스니핑으로 인한 문제 외에도 인덱스 통계의 업데이트 주기로 인한 변질된 통계로 잘못된 쿼리플랜이 생성되는경우 등 도 있음 - dc App

[백갤러 1(118.235)]

이에 대한 해법으로는 - 인덱스 통계를 주기적으로 업데이트 해주는 배치 - 쿼리 플랜을 쿼리힌트로 고정 하는 방법 등이있음 - dc App

[돌솥굴국밥(wldyd4195)]

gpt 뺨때기 후려버릴정도네 ㄷㄷ - dc App

[백갤러 1(118.235)]

이해가 안가는 키워드 기준으로 하나씩 공부하면 완벽히 이해할 수 있을꺼야 - dc App

[돌솥굴국밥(wldyd4195)]

그저 DBA 중 GOAT - dc App

[차에코푼쒸키(healthy3804)]

에이 씨 . . 개발자가 db에 너무 깊어지는거 아니야? 사실 옵티마이저 인덱스통계기반으로 실행계획을 세운다 딱 이느낌으로 알아먹고 쿼리짜는법이나 배워야지 방지수단,보조기능은 모르겠고 쿼리힌트는 사실 dba가 해줘야지! - dc App

[익명(gcghqzs9jhhk)]

근데 모든 회사에 dba가 다 있나? 일단 개좆소갈거면 알아놓긴 해야할덧

[김대기(waitkim)]

개좆소에선 저런걸 알 필요가 없다..

[김대기(waitkim)]

개발자가 저런 지식까지 상세히 알 필요는 없음 근데 알려주면 감사한 일이지 뭘 또 필요를 따지노..