#Summary
실시간 사용률이 높은 메인 비즈니스 로직에서
변질된 통계에 대한 잘못된 카디널리티 예상행갯수 으로 인해
쿼리플랜의 일부 연산자가 Scan 연산자로 컴파일되어
과도한 리소스 사용으로 인한 Database Server에 Hang상태를 유발함.
#Problem
Hang상태를 유발한 쿼리는 한개의 부모 테이블을 기반으로 하여금
자식 12개의 테이블, 30번의 Join으로 이루어져 있으며
문제1
해당 쿼리에서 릴레이션의 대부분은 1:N으로 이루어져 있으나
ResultSet에서 부모 테이블 기준으로 1개의 행당 1개의 행을 만들어 내는 쿼리로
동일 테이블에 대해 1개의 행씩 여러번 조회하여
인덱스에서 동일 리프페이지 탐색 경로에 대한 중복 io가 발생하며
문제2
그러한 테이블 중 한개의 테이블이
다른 비즈니스 로직 중 잘못 설계된 오퍼레이션으로 인해
동일한 값을 가지고 삽입/삭제가 빈번하게 발생하여
완벽한 유니크를 보장하지 않는 컬럼을 사용하는 해당 테이블의 인덱스의
통계가 상시 변질되어 있는 상태로
자동 쿼리플랜 재생성 타이밍에
위에 서술한 변질된 통계가 존재하는 테이블 탐색당시
Seek연산으로 인한 카디널리티 예상행 수치로 인해
Full Scan 연산 후 Hash Join을 사용하는 쿼리 플랜이 io, cpu time에
유리하다고 옵티마이저가 판단하여 잘못된 쿼리플랜이 생성되어
해당 쿼리를 실행시 과도한 리소스 사용으로 인해
Database Server의 Hang상태가 발생함
#Solution
문제1에 대한 Solution
- 중복 탐색 최소화를 위한 String_Agg 함수 활용 및 클라이언트 작업자에게 브리핑
문제2에 대한 Solution
안건 1). 인덱스 통계 업데이트 스케줄링
안건 2). 변질된 통계를 유발하는 비즈니스 로직을 리팩토링
안건 3). 해당 테이블을 메인테이블에 역정규화
안건 4). 쿼리플랜힌트로 고정
아마 리마큐 완벽히 이해하신 분은 다 이해하실듯.... 백엔드 좀 하시는 분들이라면 이정도 영역까지 하실 수 있지 않을까 생각하네요 - dc App
저런 미친짓으로 통계를 변질시킨다는건 상상도 못함 그리고 백엔드 개발자라면 접근법 자체가 다를듯 전문지식이 부족하기도 하고, 애초에 구조적인 문제가 있어보임
나 입사하기도 전부터 있던 레거시한 테이블인데 서비스가 커지면서 이런 문제가 생기기 시작한듯 그래서 큰 기업일수록 DA의 역할이 클꺼 같다고 느꼈음 - dc App
전에도 이야기했지만 da, dba의 역할은 점점 축소되고 있음
1. 큰 기업에는 좋은 개발자들이 있어서 그런 막장 테이블이 별로 없음. 쿼리도 마찬가지 2. 서비스가 많고 다양해서 da가 그걸 다 다룰수가 없음. 결정적으로 rdb 비중이 많이 줄었음
힝 - dc App
돈 관련된 쪽은 rdb 절대 못버릴듯 그리고 그쪽은 개같은 레거시들이 그득그득하고 개발자들도 굉장히 보수적인 성향이라 실력도 개좆같지!
야호! 쿼리똥 치우개 발사 히히 - dc App
근데 사실 막장 테이블이라고 하기에도 애매한게 확장에 용이하기 위한 최대한의 정규화가 되어있던 테이블이라 지금은 틀려도 설계당시에는 맞았을 수도 있음 약간 RDB자체의 저점을 보인것 같은 느낌 - dc App
그 전에 다른 해법을 찾지 못한게 무능의 증거지 rdb는 잘못이 없음..
멋있어. DBA가 될건 아니지만 추천해줄만한 서적 있음? Real MySQL말고
mssql 기준으로 중고급 서적 추천하면 - SqlServer 운영과 튜닝 - SqlServer 튜닝 원리와 해법 - SqlServer Deep Dive (얘는 안읽어봤는데 마소mvp들이 집필한 영어원문) 그리고 SQLP 관련 서적정도 DAP는 실무진내에서도 의견이 좀갈리더라 - dc App
고마워
솔루션2 그딴 쿼리를 작성한 개발자를 칼로 찌른다 30 조인은 악마들이나 할 생각
정답이다 연금술사 - dc App
한국말로 요약하자면. .. 니가 쿼리를 잘못짜서 innodb가 각테이블마다 정보를 얼마나 가진지 몰라서 잘못된 옵티마이저 실행계획을 세운거냐? 그런이유는..30번조인이니 대량의 정보일꺼고 hang은 뭔소리인지 모르겠고 결국 니잘못이다!? - dc App
문제2는 다음기회에 - dc App
근데 개발자가 쿼리로 똥싸면 닦아주는 dba가있으면 개편하겠네 - dc App
3줄요약하면 - 잘못된 인덱스 통계를 유발하는 로직이 잘못 - 리프페이지까지 경로에 대한 중복탐색이 잘못 - 이런쿼리가 나오도록한 기획이 잘못 - dc App
dba는 그런 세부적인걸 검사하는구나 리프페이지까지 중복탐색여부도 그래도 니가 악으로 깡으로 고쳐야함? 개발자가 30번 조인하는 이상한 설계를 해도? - dc App
요거 관련해서 DBA가 할일을 얘기하자면 애초에 이런문제가 발생하지 않도록 테이블을 설계하거나 Hang이 발생하기전에 모니터링해서 솔루션 했어야했음 내가 저거 튜닝할당시 모니터링 기술이 부족해서 사후 처리한거 복기해서 여기 쓴겨 - dc App
real my sql 은 아직 안삿는데 추천 도서에 있는 sql서버 운영과 튜닝이라는 책은 있거든?? 예전에 누가 준거 받은거라 목차도 모르는데 리마큐 안읽고 이거 읽어도 돼??
안읽는다기보단 이거 먼저 읽어도 돼?
리마큐 읽으셈 sql server 운영과튜닝은 mssql 기준이기도 하고 약간 결이 다른 책임 - dc App