datetime 타입을 가지고 group by 할때 날짜만 가지고 한다거나 할 경우
일반적으로 아래와 같이 많이들 사용하셨죠... (저도 역시나... ^^)
select convert(varchar(10), getdate(), 120)
블로그를 보다가 매우 간단하나 날짜별 집계를 할때 성능향상을 시켜주는 내용을
찾아서 공유드립니다.
백마디 말 보다는 바로 테스트를 진행해보도록 하겠습니다.
1. 로그 테이블를 테스트 기준으로 잡았습니다. 건수는 약 200만건입니다.
select count(*) from dbo.LogTable WITH (nolock)
Result>
1995925
2-1. 일반적인 방식으로 각 날짜별 플레이횟수를 수집 : CPU 시간 = 3857ms
set statistics io on
set statistics time on
select convert(varchar(10), startdate, 120), count(*)
from dbo.LogTable with (Nolock)
group by convert(varchar(10), startdate, 120)
order by convert(varchar(10), startdate, 120)
set statistics io off
set statistics time off
(377개 행 적용됨)
테이블 'Worktable'. 검색 수 0, 논리적 읽기 수 0, 물리적 읽기 수 0, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
테이블 'LogTable'. 검색 수 5, 논리적 읽기 수 26926, 물리적 읽기 수 0, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
SQL Server 실행 시간:
CPU 시간 = 3857ms, 경과 시간 = 1015ms.
SQL Server 실행 시간:
CPU 시간 = 0ms, 경과 시간 = 1ms.
2-2. Blog에 나온 방식으로 각 날짜별 플레이횟수를 수집 : CPU 시간 = 1125ms
set statistics io on
set statistics time on
select DATEADD( day, DATEDIFF(day, 0, startdate), 0), count(*)
from dbo.CBT_GameRoomLog with (Nolock)
group by DATEADD( day, DATEDIFF(day, 0, startdate), 0)
order by DATEADD( day, DATEDIFF(day, 0, startdate), 0)
set statistics io off
set statistics time off
(377개 행 적용됨)
테이블 'Worktable'. 검색 수 0, 논리적 읽기 수 0, 물리적 읽기 수 0, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
테이블 'LogTable'. 검색 수 5, 논리적 읽기 수 26926, 물리적 읽기 수 0, 미리 읽기 수 0, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
SQL Server 실행 시간:
CPU 시간 = 1125ms, 경과 시간 = 282ms. (약 3배이상 성능 개선됨)
SQL Server 실행 시간:
CPU 시간 = 0ms, 경과 시간 = 1ms.
의견.
Ø CPU 시간을 보시면 알겠지만 3배 이상의 차이가 났습니다. 가능하면 다음부터 datetime타입의 컬럼에서 날짜만
필요한 경우에는 위와 같이 사용하는 것이 좋을 듯 합니다.
Ø 코드가 복잡한 것은 아니라서 보시면 다들아시겠지만 여기서의 중요 포인트는 형변환을 안하고
가능한 현재의 타입을 유지하면서 목적하는 것을 만들어 냈다는 점입니다.내장함수라도 함수사용은
CPU를 많이 사용하므로 쿼리를 만드실 때 가능하면 형변환을 줄이는 것이 좋을 듯 합니다.
Ø 늘 쓰던 부분이라도 성능 개선을 할 수 없는지 고민하는 자세를 가져야겠다는 교훈을 얻었습니다.
@@ 출처
http://www.sqlmag.com/Article/ArticleID/94487/sql_server_94487.html
http://www.sqlmag.com/Article/ArticleID/94819/sql_server_94819.html