datetime2 설명서 (Transact-SQL) 에 따르면 :
3보다 작은 정밀도의 경우 스토리지 크기 6 바이트.
정밀도 3과 4의
경우 7 바이트. 다른 모든 정밀도에는 8 바이트가 필요합니다.
크기는 datetime2(0), datetime2(1), datetime2(2)스토리지의 동일한 양 (6 바이트)를 사용한다.
datetime2(2)추가 크기 비용없이 정밀도를 활용하여 이익을 얻을 수 있다고 말하는 것이 정확 합니까?
참고 사항 :
시겠습니까 datetime2(0)where 절에 사용하면 더 많은 CPU 효율적으로, 또는 색인을 통해 추구 할 때?
이것은 거대한 테이블이므로 가장 작은 최적화로 큰 차이를 만들 수 있습니다.
답변:
dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3)의 크기는 동일한 스토리지 양을 사용합니다. (6 바이트)
dateTime2 (3)을 사용하고 추가 크기 비용없이 정밀도의 이점을 얻을 수 있다고 말하면 정확합니까?
아니요, 설명서를 잘못 해석했습니다. 문서 는 3 미만의 정밀도 (강조 광산)에 대해 스토리지 크기를 6 바이트로 명시 합니다. 따라서 3과 같은 정밀도에는 7 바이트가 필요합니다.
밀리 초를 신경 쓰지 않는다면 datetime2(0)올바른 데이터 유형과 정밀도가 될 것입니다. 가장 좋은 방법은 저장된 데이터를 기반으로 적절한 데이터 유형과 정밀도를 지정하는 것입니다. 이는 기본적으로 최적의 스토리지와 효율성을 제공하기 때문입니다. 즉, 스토리지 크기가 동일하다면 지정된 datetime2 정밀도를 기반으로 큰 성능 영향을 기대하지는 않지만 직접 테스트하지는 않았습니다.
응용 프로그램 요구 사항에 따라 소스에서 더 높은 정밀도를 사용할 수있을 때 데이터베이스에 저장해야 할 내용이 결정됩니다. 예를 들어,에서 주문한 주문 입력 시간의 SYSDATETIME()경우 사용자는 100 나노초 정밀도를 원하지 않을 수 있습니다. 다시 한 번, 요구 사항에 따라 새로운 개발을위한 데이터 유형과 정밀도를 선택하면 일반적으로 추가 생각없이 최적의 성능을 얻을 수 있습니다.
datetime2는 위에 나열된 새로운 개발에 가장 적합하지만 레거시 datetime 응용 프로그램과의 호환성 을 위해 datetime (고정 정밀도 3 1/300 소수 초 정확도로 수정) 을 사용해야 하므로 암시 적 변환과 예기치 않은 비교 동작을 피할 수 있습니다. 소수 초 정확도 및 스토리지 증가 비용.
필요한 것보다 더 큰 정밀도를 저장하면 개발 비용이있을 수 있습니다. 전체 초 정밀도 만 필요할 때 소수 초 단위로 시간 구성 요소를 저장하는 경우, 올바른 결과를 리턴하기 위해 쿼리는 여전히 소수 초를 고려해야합니다. 예를 들어, 사용자가 전체 초만 허용하는 UI를 통해 시간 범위를 선택하는 앱의 경우 종료 시간 범위 값에서 소수 초를 설명하고 이에 따라 사용자 제공 값을 조정해야합니다 (예 : WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'또는 WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). 이것은 코드 복잡성을 추가합니다.
smalldatetimeSELECT CAST(GETDATE() AS smalldatetime);