У меня есть общая таблица журнала, около 5 м строк.
Есть «строго типизированное» поле, в котором хранится тип события, и набор «ошибочно типизированных» столбцов, которые содержат данные, относящиеся к событию. То есть значение этих «плохо напечатанных» столбцов зависит от типа события.
Эти столбцы определены как:
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,8 ГБ в пространстве данных, как сообщалось sp_spaceused
, тогда как до разбора она была 1 ГБ.
Я пытался dbcc cleantable
, но это не имело никакого эффекта.
Тогда dbcc shrinkdatabase
тоже никакого эффекта.
Озадаченный, я удалил SPARSE
и повторил dbcc
с. Размер таблицы остался на уровне 1,8 Гб.
Что дает?
rowid int not null identity(1,1) primary key clustered
.Ответы:
Вам нужно перестроить кластерный индекс после того, как столбцы будут редкими. Пропущенные столбцы все еще существуют на странице данных, пока вы не сделаете это, как можно увидеть с помощью запроса
sys.system_internals_partition_columns
или использованияDBCC PAGE
источник