주문상세보기 쿼리인데요 컬럼을 25개 정도 뽑아야 합니다.
한 주문건에 주문제품이 많지 않을 경우에는 문제가 없는데
주문제품이 20개 이상 정도 될경우에는
불러오는데 3~5초 정도 걸립니다.
가끔 불러오면 별로 문제가 안되는 시간인데
자주 불러오니까 그 시간도 거슬린다고 하네요
select p_number, p_name, p_ea, p_unit, p_local, p_cost, p_tax, p_sum, p_trans_real_date, p_real_name, p_bigo, p_real_buy, p_real_ea, p_real_unit, p_com_name, p_sticker, isnull(p_real_buy,0) p_real_buy, isnull(p_real_tax,'') p_real_tax, isnull(p_real_tax_price,0) p_real_tax_price, isnull(p_real_sum,0) p_real_sum, p_number, idx, is_order, p_tax_icon, p_real_bigo from 주문제품테이블 where sumt_idx=1 order by idx asc
현재 주문제품테이블 에
idx 쪽에 클러스터 인덱스
sumt_idx에 인덱스 가 걸려있습니다.
잠깐 찾아본 봐로는 커버드 인덱스를 해야 된다고 하는데
조회를 하는 컬럼이 많아서 가능한지..
실행계획은 첨부파일로 올렸습니다.
도움 부탁 드립니다.
Comment 7
-
냥냥
2013.11.12 17:31
현재는 클러스티드 인덱스가 일련번호 컬럼으로 되어있는데요..
복합 인덱스로 만드는 걸 말씀하시는 건가요?
-
딱 저 쿼리 하나만을 튜닝한다면 제일 비용을 많이 차지하는 KeyLookup을 없에는게 방법일거 같아서 제안을 드린겁니다.
KeyLookup을 없에려면
sumt_idx를 넌클러스터드 인덱스로 만들면서 select 절의 모든 컬럼을 include 시키는 방법이 있겠고 (좀 무식)
sumt_idx를 클러스터드로 만드는 방법이 있습니다. (기존 Clustered는 Non Clustered로 변경)
저 두 방법중 하나를 쓰면 일단 저 쿼리는 빨라질거 같습니다.
하지만 튜닝이란게 하나의 쿼리만 대상으로 할 수는 없습니다.
인덱스를 변경하려면 주문제품테이블에 엑세스하는 모든 쿼리를 바뀐 인덱스 하에서 평가를 해봐야죠.
테이블 하나를 더 만들고 거기에 인덱스를 추가한 다음 테스트 해보세요.
-
맨즈밤
2013.11.12 17:02
느려졌을때의 실행계획을 첨부한게 맞으시죠? 음...이상한데요.. 집계데이터도 아니고,,것도 index seek를 통해서 데이터를 겨우 20개정도 불러오는데 , 너무 느립니다.
디비쪽에서 그렇게 지연되는게 맞나요? 유저가 보기에 그렇게 느려진다면 응용프로그램에서 어떠한 처리로 인해 느려질수도 있다고
보여집니다.
-
냥냥
2013.11.12 17:32
불러오는 데이타는 작아도 해당 테이블의 총 갯수가 현재 15만개정도 되는데 이것때문에 그럴까요?
불러오는 페이지에서는 따로 처리하는 게 없는데 이상하네요..
-
kk
2013.11.15 17:13
실행계획 이미지 말고, 실행계획 파일을 볼수 있을까요 ?
-
냥냥
2013.11.19 00:16
음.. 제가 헛짓을 했었네요..
데이타를 뿌려줄때 input 박스에 값을 넣어주는 방식인데
input 관련 css 에 expression 이 들어간 구문 때문에 느려진거네요
css 때문에 속도가 엄청 나이가 난다고 생각 못했는데
css 에 expression 구문은 되도록 안 쓰는게 좋다고 하네요~
IX_Product_Psumt를 클러서터드 인덱스로 바꾸면
Key Lookup이 사라지면서 빨라질것 같습니다.