데이터베이스를 사랑하는 사람들의 모임 데이터베이스 사랑넷

datetime 은 8바이트이고 정수부(연도) 4바이트 + 소수부(시간) 4바이트로 구성됩니다.
smalldatetime 은 4바이트이고 정수부(연도) 2바이트 + 소수부(시간) 2바이트로 구성됩니다.

내부 코드를 알지 못하니 동작도 정확하게는 알수가 없지만
기본적으로 32bit 코드라면 데이터 처리를 4바이트씩 할테니 단순하게 생각하면
smalldatetime 이 더 빠르다고 생각될 수도 있습니다.
하지만 이것도 좀 더 세부적으로 생각해보면 쿼리의 형태에 따라 그렇지 않을 수도 있는데요.
특정 시각 비교일 때는 8바이트와 4바이트로 분명 smalldatetime 이 더 빠들것 같지만
날짜만 비교한다면 과연 smalldatetime 이 더 빠를 것인가 의문입니다.
왜냐하면 날짜만 비교한다면 datetime 은 앞 4바이트만 비교하면 되고
smalldatetime 은 4바이트에서 다시 앞 2바이트를 추출하거나 아니면
32bit 비교에서 앞 16bit에 대한 마스크로 비교하겠지요.

select convert(datetime,2958463.555555556), convert(smalldatetime,65535.555555)

사실 datetime 이 성능에 영향을 주는 쿼리가 어떤것인지 잘 모르겠습니다만
smalldatetime 은 날짜 한계가 2079년으로 그뒤로도 사용될 프로그램이라면
사용하지 않아야 하는 타입이라고 볼수 있습니다.
아니면 70년 뒤에 필드를 수정하셔도 되구요. ^^;
실시간 통계가 아니라면 datetime 이 영향을 줄만한 쿼리가 얼른 안떠오르네요.

아래는 테스트
create table test_datetime (
id int identity not null primary key,
num float,
c_datetime datetime,
c_smalldatetime smalldatetime
)

insert into test_datetime (num,c_datetime,c_smalldatetime)
values (50000*rand(0),50000*rand(0),50000*rand(0))

insert into test_datetime (num,c_datetime,c_smalldatetime)
select 50000*rand(id), 50000*rand(id), 50000*rand(id)
from test_datetime

여러번 실행(테스트는 800만개)

아래쿼리에서 문자열로 들어간 시각은 암시적으로 형변환됩니다.

select * from test_datetime
where c_datetime = '2000-01-01 01:23:45.667'

select * from test_datetime
where c_smalldatetime = '2000-01-01 01:23:45.667'

두쿼리 비용 50%로 동일(풀스캔)
가져온 row수 0건, 0건
실행시간 42초
-----------------------------------------------
select * from test_datetime
where c_datetime > '2000-01-01 01:23:45.667'

select * from test_datetime
where c_smalldatetime > '2000-01-01 01:23:45.667'

두쿼리 비용 50%로 동일(풀스캔)
가져온 row수 2,318,555건, 2,318,555건
실행시간 3분 46초
-----------------------------------------------
create index idx1 on test_datetime(c_datetime)

create index idx2 on test_datetime(c_smalldatetime)

쿼리비용 51.17%, 48.83%
(크기에 따라 IO 비용이 다르긴 다른가 보네요. 800만건에 대한 예상보다는 작은수준)
실행시간 2분16초
-----------------------------------------------
select * from test_datetime
where c_datetime = '2000-01-01 01:23:45.667'

select * from test_datetime
where c_smalldatetime = '2000-01-01 01:23:45.667'

두쿼리 비용 50%로 동일(인덱스seek)
가져온 row수 0건, 0건
실행시간 0초
-----------------------------------------------
select * from test_datetime
where c_datetime > '2000-01-01 01:23:45.667'

select * from test_datetime
where c_smalldatetime > '2000-01-01 01:23:45.667'

두쿼리 비용 50%로 동일(인덱스 걸었지만 풀스캔함)
가져온 row수 2,318,555건, 2,318,555건
실행시간 4분 35초
-----------------------------------------------
select top 100 * from test_datetime
order by c_datetime desc

select top 100 * from test_datetime
order by c_smalldatetime desc

두쿼리 비용 50%로 동일(인덱스scan)
가져온 row수 100건, 100건
실행시간 0초
-----------------------------------------------
select * from test_datetime
where c_datetime > '2036-11-22 01:23:45.667'

select * from test_datetime
where c_smalldatetime > '2036-11-22 01:23:45.667'

두쿼리 비용 50%로 동일(인덱스seek)
가져온 row수 159건, 159건
실행시간 0초
-----------------------------------------------

이 테스트가 모든걸 보여주지는 못하겠지만
비슷한 필드일 경우 단지 크기가 작다고 해서 성능이 비례해서 증가하지는 않을거 같습니다.
insert, update, delete 가 현저하게 많다면 약간 다른 문제겠지만요.
정말 중요한 것은 테이블에 대한 설계와 성능을 향상시킬 수 있는 쿼리가 아닌가 합니다.

맛박님이 2007-06-05 19:15에 작성한 댓글입니다. Edit Ｘ