728x90
반응형
저장 프로시저내에 다음과 같은 쿼리가 있었습니다.
하지만, 특이하게도 특정한 경우에 부하가 많이 걸려서 성능이 제대로 나오지 않는 경우가 있었습니다.
linked_isn1과 linked_isn2 각각의 컬럼에 독립적으로 인덱스가 잡혀 있었는데, 어느 때는 읽기 수가 1000이상이 나오면서 갑작스럽게 느려졌었습니다.
그래서 결국은 아래와 같이 IF문 형태로 코드를 변경하였습니다. 그랬더니, 이전과 같은 문제가 발생하지 않더군요.
재미있는 것은 아래의 실행계획입니다.
OR를 사용하게 되면, 내부적으로 JOIN 등의 연산이 필요한데, IF 문으로 바꾸었더니, 매우 간결한 실행결과로 나왔고, 비용도 OR를 사용했을 때보다 50%나 감소했음을 알 수 있습니다.
이런 점들을 하나하나 보다보면 SQL은 참 신기하기도 하고, 재미나기도 합니다. ^^
하지만, 특이하게도 특정한 경우에 부하가 많이 걸려서 성능이 제대로 나오지 않는 경우가 있었습니다.
DECLARE @ISN INT, @parent_ISN INT SET @ISN = 123142 SELECT @parent_ISN=ISN FROM TEST_DB.dbo.test WITH (NOLOCK) WHERE 1 = 1 AND (linked_isn1 = @ISN OR linked_isn2 = @ISN)
linked_isn1과 linked_isn2 각각의 컬럼에 독립적으로 인덱스가 잡혀 있었는데, 어느 때는 읽기 수가 1000이상이 나오면서 갑작스럽게 느려졌었습니다.
그래서 결국은 아래와 같이 IF문 형태로 코드를 변경하였습니다. 그랬더니, 이전과 같은 문제가 발생하지 않더군요.
DECLARE @ISN INT, @parent_ISN INT SET @ISN = 123142 SELECT @parent_ISN=ISN FROM PAPERS.dbo.articles_extra WITH (NOLOCK) WHERE 1 = 1 AND linked_isn2=@ISN IF @parent_ISN IS NULL BEGIN SELECT @parent_ISN=ISN FROM PAPERS.dbo.articles_extra WITH (NOLOCK) WHERE 1 = 1 AND linked_isn1=@ISN END
재미있는 것은 아래의 실행계획입니다.
OR를 사용하게 되면, 내부적으로 JOIN 등의 연산이 필요한데, IF 문으로 바꾸었더니, 매우 간결한 실행결과로 나왔고, 비용도 OR를 사용했을 때보다 50%나 감소했음을 알 수 있습니다.
이런 점들을 하나하나 보다보면 SQL은 참 신기하기도 하고, 재미나기도 합니다. ^^
'DB > MS-SQL' 카테고리의 다른 글
MS-SQL 2005에서 백업 받은 DB를 복구한 이후 발생하는 로그인 불일치(Orphaned Users) 문제 해결 방법 (0) | 2009.08.13 |
---|---|
Owner 속성 오류로 데이터베이스(DB) 속성창이 열리지 않는 문제. (0) | 2009.07.09 |
저장 프로시저 및 함수의 소스 코드에 특정 키워드가 들어 있는 것 찾기 (0) | 2009.06.05 |
분산 트랜잭션 설정 (4) | 2009.04.04 |
AWE(Address Windowing Extension)의 사용(MS-SQL 2005) (2) | 2009.03.17 |