Saya memiliki tabel log generik, sekitar 5m baris.
Ada bidang "sangat diketik" yang menyimpan jenis acara, dan sekelompok kolom "diketik dengan salah" yang berisi data yang relevan dengan acara tersebut. Artinya, arti kolom-kolom "diketik dengan keliru" tergantung pada jenis acara.
Kolom-kolom ini didefinisikan sebagai:
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
Kolom 1 dan 2 di masing-masing jenis banyak digunakan, tetapi mulai dari nomor 3, sangat sedikit jenis acara yang menyediakan informasi sebanyak ini. Karena itu saya memutuskan untuk menandai kolom 3-5 di setiap jenis sebagai SPARSE
.
Saya melakukan beberapa analisis terlebih dahulu, dan melihat bahwa, memang, setidaknya 80% dari data di masing-masing kolom adalah null
, dan di sekitar 100% dari data null
. Menurut tabel ambang penghematan 40% , SPARSE
akan menjadi kemenangan besar bagi mereka.
Jadi saya pergi dan melamar SPARSE
kolom 3-5 di setiap kelompok. Sekarang meja saya membutuhkan sekitar 1.8Gb dalam ruang data seperti yang dilaporkan oleh sp_spaceused
, sedangkan sebelum sparsing adalah 1Gb.
Saya mencoba dbcc cleantable
, tetapi tidak berpengaruh.
Lalu dbcc shrinkdatabase
, tidak ada efek juga.
Bingung, saya menghapus SPARSE
dan mengulangi dbcc
. Ukuran tabel tetap di 1.8Gb.
Apa yang menyebabkannya?
rowid int not null identity(1,1) primary key clustered
.