약 5m 행의 일반 로그 테이블이 있습니다.
이벤트 유형을 저장하는 "강력한 유형"필드와 이벤트와 관련된 데이터가 포함 된 "손실 된 유형"열이 있습니다. 즉, "손실 된 유형"열의 의미는 이벤트 유형에 따라 다릅니다.
이 열은 다음과 같이 정의됩니다.
USER_CHAR1 nvarchar(150) null,
USER_CHAR2 nvarchar(150) null,
USER_CHAR3 nvarchar(150) null,
USER_CHAR4 nvarchar(150) null,
USER_CHAR5 nvarchar(150) null,
USER_INTEGER1 int null,
USER_INTEGER2 int null,
USER_INTEGER3 int null,
USER_INTEGER4 int null,
USER_INTEGER5 int null,
USER_FLAG1 bit null,
USER_FLAG2 bit null,
USER_FLAG3 bit null,
USER_FLAG4 bit null,
USER_FLAG5 bit null,
USER_FLOAT1 float null,
USER_FLOAT2 float null,
USER_FLOAT3 float null,
USER_FLOAT4 float null,
USER_FLOAT5 float null
각 유형의 1 열과 2 열은 많이 사용되지만 3 번부터는 많은 이벤트 유형이 이러한 많은 정보를 제공합니다. 따라서 각 유형에서 3-5 열을로 표시하고 싶습니다 SPARSE
.
먼저 몇 가지 분석을 수행 한 결과 실제로 각 열의 데이터 중 80 % 이상이 데이터 null
이고 100 %가 데이터 인 것을 알았습니다 null
. 40 % 절감 임계 값 표 에 따르면 , SPARSE
그들에게 큰 승리가 될 것입니다.
그래서 나는 가서 SPARSE
각 그룹의 3-5 열에 적용 했습니다. 이제 내 테이블은에 의해보고 된 데이터 공간에서 약 1.8Gb를 차지 sp_spaceused
하지만 스파링하기 전에는 1Gb였습니다.
시도 dbcc cleantable
했지만 효과가 없습니다.
그런 다음 dbcc shrinkdatabase
아무 효과도 없습니다.
의아해, 나는 s를 제거 SPARSE
하고 반복했다 dbcc
. 테이블 크기는 1.8Gb로 유지되었습니다.
무엇을 제공합니까?
rowid int not null identity(1,1) primary key clustered
있습니다.