존나 깔 껀덕지도 없는 단순한 코드를 붙잡고 하는 말이,
A join B join C where a and b and c 보다, (subQuery A where a) join (subQuery B where b) join (subQuery C where c) 가 더 빠르대.
이거 안해서 존나 갈굼당함....
저렇게 해야 조인을 하기 전에 미리 웨어절로 조인할 칼럼 수를 줄여놓고 조인한다고 더 빨라진대
아니 그럼 시발 모든 조인을 다 서브쿼리로 하고 가면.....
일단 JPA에서 프롬 조인 서브쿼리 안되는 고로
차선책으로 모든 조인을 풀어서 썼음.
A에서 웨어를 적용하고,
추려진 A를 통해서 B를 뽑아올때 조인컬럼에 where 줘서 간추리고 뽑았음.
일단 조인을 하나도 안하고 직접 다 쿼리 개별적으로 날려서 해결했음.
빨라지긴 빨라지더라
0.7초짜리 쿼리가 0.3초로 줄어들긴 했음.
일단 난 0.7초짜리 쿼리들 보고 나보고 백엔드 문제 존나 많다고
나를 청소해야하는 문제덩어리로 보는것도 짜증나고
성능개선이거 하드웨어문제인거 확신하고나니까 더 어이가없었음.
그럼 대기업들은
join하나도 맘대로 안함???? 당연히 조인할 필요성이 있는 경우 얘기임. 조인을 남용했다는것도 아니고
조인 해야할때 조인하지말고 조인을 풀어헤치거나 서브쿼리에다가만 조인하라는건데
그렇다면 sql 그냥 이거 쓰레기 병신인데???
생산성 좆구린 병신물품.
jpa는 서브쿼리 안먹히니까 그냥 폐급 쓰레기고.
그냥 뭐 언어가 아니라 어셈블리 인데????
하드웨어가 병신인거 알고나니까 더 병신같다.
그래서 조인할때마다 서브쿼리에다가 조인함?? 대기업들은 그럼? ㅋㅋㅋㅋㅋㅋ
조인할때 서브쿼리 안썼다고 폐급되는거임???
글구 0.7초짜리 쿼리는 뭐 쿼리 누가짰냐는 소리 들어야할정도로 폐급인거임?
그냥 앱이 느려 씨발. 그게 문제인데 자꾸 뭐 코드가 어쩌구저쩌구. 이건 백엔드가 신입이라 병신이라서 그럴거라느니 (나 혼자 담당)
https://9romit.com/sql-join-완벽-가이드-테이블-연결의-모든-것-inner-left-right-full/
조인 풀어헤쳐서 0.7초 0.3초로 만든거 코드 씹창났어.... 프로젝션 여러번하고 그거 합치고, 쿼리 여러번쏘고, 프로젝션 분할되어있으니까 DTO이름도 병신났고
서브쿼리가 있다면 뭐 나도 공감은 함. 더 빨라지는 방법이있다면 쓰는게 맞지. 좀 좆같긴해도 (자동화되어야할 영역이 수동화되어있으니까 좆같고)
힘내 그런 걸로 힘들어 하지마 ㅇㅅㅇ 딱국이는 공부할 때 생각이 남달라서 신기한 생각 많이함 멀리 보면 괜찮을 듯 ㅇㅅㅇ
나트륨찡 너 참 귀엽구나
걍 JPA 문제 아님? A join B join C where a and b and c 이거 실행계획은 서브쿼리랑 똑같을거 같은 느낌인데
ㄴㄴ 더 빨라지긴 더 빨라졌었음
아 그게 느린게 JPA문제라고? 실제 sql에선 상관없다는말인가?? 근데 상관 있긴 하던데
조인 조건이 pk끼리 하는거면 차이가 날 것 같진 않아서...
아우터 조인하는거면 순서 문제일수도?
조인하는 갯수가 달라지나봐. 서브쿼리로 간추린 테이블은 로우 갯수가 현저하게 줄어드니까, 테이블을 곱한다음 간추리기보다, 간추려서 곱하는걸 하는 방식인가봄
이너조인이더라도, (subquery A where a) 에서 간추려진 대상들은 조인에서 빠지게 되니까 더 간추려지긴 하잖아
최적화 없으면 그렇긴 한데 옵티마이저가 이런 기본적인 조인 최적화를 못하나 흠
ㅇㅎ.... 근데 너 말이 맞을수도 있어
아, 일단 나같은경우는 limit 이 문제였음. 단순 웨어절은 아니고, limit을 서브쿼리안에 집어넣어서 limit10을 먼저하고 그다음에 조인하라는게 원인이었는데 limit쪽은 좀 다를지도?
리밋도 최적화 해준다면 해줄수있을거같긴한데, 여하튼 최적화란게 따로 있다면 리밋때문에 그럴지도?
아우터 조인하고 있음? 그럼 옵티마이저가 최적화하기 어렵긴 함
0.7 => 0.3 성능개선은 사용자체감속도는 0인 수준이라 득은 없고 그저 자기부심인듯허다 그런거에 스트레스받지마라
사용자 체감속도가 현재 느려. 왜? 메인화면에서 0.3초 0.7초 0.4초 0.2초 짜리 api요청을 동시ㅔ에 쏘는데, 서버가 동시에 여러개의 리퀘스트를 받으면 존나게 느려져서 죄다 2초이상씩 걸림.
이건 하드웨어 문제지.....
하드웨어문제를 나보고 쿼리 병신같이 짰다고 뭐라 하는 중임. 내가보기엔
튜닝이 1초 언던인거 하나씩잡아서 체감느낄 정도에 성능확보가 어렵자나 왕건이 하나 잡아서 튜닝해야 체감이들지 너가 처한 상황도 어려운데 주변동료는 빌런들만 가득한 환경인가보다
븅신아 데이터 조회량이 적어지면 빨라지는게 당연한거 아니냐 이새끼는sql문법 간단한거조차모르나 좀더 처갈궈야지 니선임 존나천사네
병신아 그럼 조인할때마다 다 서브쿼리로 간추려서 쿼리짜고앉아있냐? 아예 웨어절마다 이건 어느 서브쿼리 선에서 넣어야하는지도 최적화하고 서브쿼리도 계층 나눠서 웨어절 박아야지. A B 순서쌍에 걸어야하는 where 절같은 경우는 A서브쿼리, B서브쿼리 각각 짜서 그 안에 A를위한 where B를 위한 where 박고, A B 서브쿼리로 묶어서 AB두개만을 위한 하지만 개별적으로는 적용 못하는 웨어 박고, C박고, 시발 이걸 언제 다만들고있냐. 그냥 조인하면 될걸
니말은 반복문 전부다 루프풀기 하라는 소리랑 똑같음. 조인을 서브쿼리로 풀어헤치는게 (심지어 jpa쓰고있어서 그냥 생으로 서로 다른 두개의 쿼리로 분할하는게) 루프풀기랑 동일한 노력이지 덜하진 않았다
이새끼 풀발했노
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
메인화면에 쓰이는 쿼리라면 0.3초도 느린거 같은데ㅇㅅㅇ
버튼눌러서 들어가는 api가 있음. 그걸 바깥에서 미리보기 느낌으로 보여주는거임
미리보기면 느린거 맞음 sql 개선이 어려우면 캐시 필요할듯ㅇㅅㅇ
그냥 막말하는거임?? 미리보기란 단어가 도대체 무슨 정보가 있다고 미리보기면 느린거임??? 버튼 안누르고 api 호출한거라고 메인화면에서. 요기요같은 경우면 메인화면에서 버튼들 박혀있는거 아래로 바로 추천하는 맛집들 장소리스트 띄워준거
메인화면에서는 0.3초도 느리다 라는건 그럼 기획쪽에서 들어가야할 문제고, 내 입장에서는 그냥 버튼눌러서 들어가는 api랑 똑같은데 0.3초면 느리다고 하는건 뭐 그냥 답 없음. 10만개 데이터 테이블을 쓰는데 거기서 조회만 해도 0.3초 걸림. 깡통으로 쿼리문만 날려도
음... 0.1초 나오긴 할거같다. 0.1이랑 0.3이랑 비교해서 0.3이 느리다고 하는거면 뭐 그럴수도있겠네
몇개 미리보기 하는데 10만개 데이터를 다 뒤져야 한다면 설계가 잘못됐지ㅇㅅㅇ
미리보기가 무슨뜻임? 목 데이터말하는거임??? 몇개 미리보기하는데 전체 데이터를 다 뒤져야하는건 개발문제가 아니라 기획문제지. 목데이터로 미리보기하는거면 그냥 쿼리할거도없이 정적으로 쏴주면 되는거고
캐시하는건 좋은 생각인듯
아예 유저도 없는데, 유저별로 메인화면에서 쏘는 인자도 똑같고 반환값도 똑같으면 (아니면 반환값을 1일 단위로 갱신하게 하면 되고) 전부 그대로 값 보내주는걸로 하면 해결되겠다
개발은 기획의 요구사항을 충족시켜줘야 하는거임. 물리적으로 불가능한게 아닌 이상ㅇㅅㅇ
프갤로 너 챗지피티같다
너 말이 맞아 프갤로
왤케 말대답함?
근데 이건 글쓴이 경력, 봉급이 어느정도냐에 따라 다를거 같다
입장바꿔서 니보다 많이 받는넘이 더 못하면 안빡치냐?
속도 안나오는 건 대부분 스키마 설계 부터 잘못된 경우가 대부분임, 서버에서 join 작업을 하니까 느릴 수 밖에 없는거임, 마지막 데이터만 저장하는 캐쉬 테이블을 만들던가 해야함 - dc App
수 밖에->수밖에 던->든 쉬->시
백엔드문제
레디스로 캐싱 허쉴~ ㅇㅅㅇ?
싹다 캐시해 ㅋㅋ
개소리임 더빨라졌다는건 캐시되어서 그런거고 저정도 서브쿼리 조인문은 옵티마이져가 알아서 실행계획짬 trace 확인해서 pr,cr 봐봐
프갤 오랜만에 왔더니 첫 글부터 ㅅㅂ ㅋㅋㅋㅋㅋ
on 절 어딧냐.. 그냥 조인 박냐? 데이터 몇갠데 그래 쿼리가 너무 무지성인데 그려
jpa가 on 알아서 해줌. 연관관계의 주인인 컬럼 기준으로.
얼핏봐도 헛다리잡는중이네 걍 지가 문제라고 생각하는부분 올려뒀는데 그게 문제도아니고 문제를 올릴거면 풀로 올리던가 올리질 마라
내가 헛다리잡았냐??? 글구 실제로 더 빨라지긴 했음 쿼리바꿔서
근데 쿼리 바꿀때, 서브쿼리 두개 어정쩡하게 셀렉트절에 들어있었는데, 그거 두개를 조인으로 빼서 한번의 쿼리로 바꾼 영향도 있을 수 있음. 그게 클 지도
던->든
클 지->클지
딱히 헛다리는 아닌데 그거 데이터가 쌓이면 쌓일수록 실행시간은 기하급수적으로 늘어난다. 니 방식대로하면 WHERE절보다 조인이 먼저라서 모든데이터들을 조인하고나서 WHERE들어가서 조인할때 코스트가 많이 소모됨. 그래서 기준이 되는 테이블을 서브쿼리안에서 WHERE로 검색범위 제한하면 후에 조인되는 테이블들의 검색범위가 많이 줄어들지.
그리고 서브쿼리로 조건을 제한하면 PK인덱스로 빠르게 검색할수있으니까 더욱 더 속도가 빠른거고.
jpa에서 안되면 db에서 view로 해결해보셈.
욱 더->욱더
predicates push down을 지원하는 dbms가 아닌가보지.
이건 혼날만한데 피드백해주는 좋은 상사네
스타트업이냐? 내가 사장이면 백엔드 바로 내보냄
자기 은근 대기업이라고 자랑하는글
퀴리 dsl쓰면 서브쿼리 쌉가능 - dc App
이뭐병.. 쿼리에서 속도가 얼마나 중요한데 ㅋㅋㅋ 한심하다. - dc App
병신아 그래서 jpa 좆구데기라 마이바티스로 옮겨간다. 글구 객체중심의 쿼리가 중요하면서 jpa 빨던새끼들이 이때다 싶어서 성능튜닝 필수라고 몰아가네 ㅋㅋㅋㅋㅋㅋ
니말대로면 jpa같은 기술은 그냥 병신 기술인거임. 한 측면만 보고 지랄하지마셈. 뭐 어차피 물어뜯기위해서 아무말이나 지껄인새끼겠지만ㄴ
jpa쓰고있는거 다 옮긴다거나 바꿀 생각 없고, 성능 필요한 영역만 마이바티스 쓸 생각
이새끼 소설 쓰고자빠졌네. 좆소커뮤니티 사이트나 속도 신경안쓰지 개솔하네 - dc App
현직 dba인데 jpa로 하면 뭐 어떻게 되는진 모르겠으나 join과 where절을 사용할 경우 옵티마이저가 join하기전에 where절로 테이블 사이즈 줄이고 join을 시도함 그래서 전자나 후자나 같다는 거지 근데 작성자가 풀 쿼리를 올리지 않아서 정확히 어떻게 짠건지도 모르겠고 jpq가 쿼리변환을 어떻게 하고 db로 넘기는지도 모르겠노 ㄹㅇ
한번 실험해봄
이런 저능아글에 추천수 뭐냐;; 폐급새끼들 폐급대전인가 - dc App
ㅋㅋ 설명을 이따구로하고 좋은 말을 듣기 바라냐. 실행계획 갖고와야지..
0.7 => 0.3은 차이가 0.4초니깐 좆밥이네? 라고 생각하는 니새끼는 나였음ㄹㅇ 무선키보드로 대가리 부셨음ㅇㅇ 저거 한번실행이아니라 누적인데 귓방망이 마려울듯
옵티마이저 힌트를 써라 진지해 보이는 글이라 성실히 답변해준다 sql 튜닝 관련 자격증(SQLP) 공부해보면 알겠지만 존나 재밌는 분야다 니가 말한 건 조인튜닝에 해당되는 내용인데 옵티마이저 힌트만 잘 쓰면 니가 쓴 쿼리에서 subquery범벅 쿼리로 바꿀수도 있다 그리고 인덱스 설정이나 조인 순서 조인방법에 따라서도 성능이 달라지니깐 실행계획하
확인하셈
친절한 sql 튜닝 이책이 입문서인데 재밋게 볼수있다
좀 더 관심이 생기면 오라클 성능 고도화 원리와 해법 보거나 회사에서 쓰는 db (mysql일거같지만) 에서 튜닝법 공부하면 된다
그리고 실행계획을 확인해라 초로 더 빠르네 이렇게 생각하지말고. 인풋량이나 데이터 분포에 따라 너가 테스트할 땐 빨랐던 쿼리가 실제 서비스 중일땐 다 느릴수도 있다
sql튜닝의 매력은 쿼리문 하나를 바꿨을 뿐인데 성능이 1000배까지 향상되는 기적과 같은 경험을 할 수 있다 30배는 우습고 비일비재하다. 넌 이유를 따지고, 보통사럼들처럼 그런갑다하고 넘어가는 스타일이 아닌것 같아 길을 하나 알려준거다. 열심히 공부해서 연봉 뻥튀기해라 참고로 sql튜닝 전문가는 연봉 1억 우습다
댓글보고 많이 배워간다