select
(select count(*) from ens_package_lecture_list where lectureseq = ens_lecture.seq) as packagecount,
(select count(*) from ens_content where lectureseq = ens_lecture.seq and enabled = true and signcode is not null) as contentcount,
(select sum(playtime) from ens_content where lectureseq = ens_lecture.seq and enabled = true and signcode is not null) as playtime,
(select count(*) from ens_wishlist where seq = ens_lecture.seq and goodtype = 1) as wishcount,
(select count(*) from ens_comment where seq = ens_lecture.seq and goodtype = 1) as commentcount,
ens_lecture.seq as seq,
view_menu.categoryseq as categoryseq,
ens_lecture.count as count,
ens_lecture.signdate as signdate
from
ens_lecture left outer join view_menu
on
ens_lecture.categoryseq = view_menu.categoryseq
뷰 만들때 크리에이트 문인데 .. 몇개 쫌 짤랐고요.. 컬럼이 서브쿼리로 되있는게 지금은 5개인데 원래는 11개 되네요.. 리스트로 이 많은 정보들을 나타내려고 해서 이렇게
만들고 쓰고 있었는데 데이터가 좀 많아지면서 심각하게 느려지더라고요..
서브쿼리로 된 컬럼이 속도에 많이 영향 줄 것 같은데 튜닝을 어떻게 해야할지 조언좀 부탁드립니다.
# 테이블들은 색으로 진하게해놨습니다. 보기 편하시라고..
아주 시밤 전화번호부 쿼리네.. ㅋㅋㅋㅋㅋ 결과물 존나 아스트랄 할듯. ㅋㅋㅋㅋ 인덱스는 알아서 걸으셨을꺼고.. 나라면 순수하게 쿼리를 이용하는것 보다는 결과 몇개를 XML 로 저장 한다음에 그걸 연동해서 쿼리 날릴듯.. 이런 쿼리라면 이건 join 써도 노답임..
가마 이쓰봐.. 일단 이거 그냥 포기 하지말고 Mysql Workbench 로 릴레이션 부터 해보센. 근데.. 그래도 좆같은건 좆같은거임 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 와 시발 이게 짜장면 이야 스파게티야 ㅋㅋㅋ 존나 똴똴 꼬아놨네 ㅎㅎ
와 이거... 좀..
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
기본적으로 아우터조인을 쓴 이유가 명확해야한다. 아우터조인을 할경우 전부표시하려고하는 테이블을 무조건 풀스캔한다는건 알고있겠지? 이쿼리 그닥 꼬아놓은거라고 하긴 어려옴. 컬럼마다 다른테이블 참조하는경우는 흔한데 문제는 count와 sum같은 함수들은 전체범위처리라서 결과가 전부나오기전까진 응답을 하질않음. 리스폰스타임이 느리다고표현한다. 이런게 느려지면 실행계획을 정확히 보고 옵티마이저가 어떻게처리하는지 봐야한다. 예를들어 얘기하면 첫째컬럼에서 ens_package_lecture_list 테이블을 참조하여 카운팅하는데 이거 풀스캔하는지 인덱스를 타는지, 하나하나 살펴봐야한다. 조언을 주려면 이 테이블의 ERD랑 현재실행계획, 아우터조인의 이유 등을 정확히 이야기해라.
테이블 관계 좆같이해놓고 프로그램단에서 어찌저찌 헛짓거리해가며 하는거보다 테이블설계 제대로하면 OLTP시스템같은경우 말도안되게 빨리진다