Tengo una tabla de registro genérico, aproximadamente 5 millones de filas.
Hay un campo "fuertemente tipado" que almacena el tipo de evento, y un montón de columnas "tipadas de forma incorrecta" que contienen datos relevantes para el evento. Es decir, el significado de esas columnas "mal escritas" depende del tipo de evento.
Estas columnas se definen como:
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
Las columnas 1 y 2 en cada tipo se usan mucho, pero a partir del número 3, muy pocos tipos de eventos proporcionarían tanta información. Por lo tanto, decidí marcar las columnas 3-5 en cada tipo como SPARSE
.
Primero hice un análisis, y vi que, de hecho, al menos el 80% de los datos en cada una de esas columnas es null
, y en aproximadamente el 100% de los datos null
. Según la tabla de umbral de ahorro del 40% , SPARSE
sería una gran victoria para ellos.
Así que fui y apliqué SPARSE
a las columnas 3-5 en cada grupo. Ahora mi tabla ocupa aproximadamente 1.8 Gb en espacio de datos según lo informado por sp_spaceused
, mientras que antes de ahorrar era de 1 Gb.
Lo intenté dbcc cleantable
, pero no tuvo ningún efecto.
Entonces dbcc shrinkdatabase
, tampoco tiene efecto.
Perplejo, me quité SPARSE
y repetí el dbcc
s. El tamaño de la mesa se mantuvo en 1.8Gb.
¿Lo que da?
rowid int not null identity(1,1) primary key clustered
.