約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に適用しました。現在、私のテーブルはsp_spaceused
、によって報告されたようにデータスペースで約1.8Gbを使用していますが、スパースする前は1Gbでした。
試しましたdbcc cleantable
が効果がありませんでした。
その後dbcc shrinkdatabase
、影響もありません。
困惑し、私SPARSE
はdbcc
s を削除して繰り返しました。テーブルのサイズは1.8Gbのままでした。
何ができますか?
再現してみます。テーブルがヒープであるか、それともクラスター化インデックスがあるかによって、違いが生じる場合がありますか?
—
マーティン・スミス
@MartinSmithにはクラスター化インデックスがあります
—
GSerg
rowid int not null identity(1,1) primary key clustered
。