490 M satır ve 55 GB tablo alanı olan bir tablo var, bu yüzden satır başına yaklaşık 167 bayt. Tablonun üç sütunu vardır: a VARCHAR(100)
, a DATETIME2(0)
ve a SMALLINT
. VARCHAR
Alandaki metnin ortalama uzunluğu yaklaşık 21,5'tir, bu nedenle ham veri satır başına yaklaşık 32 bayt olmalıdır: için 22 + 2, için VARCHAR
6 DATETIME2
ve 16 bit tamsayı için 2.
Yukarıdaki alanın yalnızca veri olduğunu, endeks olmadığını unutmayın. Özellikler | altında bildirilen değeri kullanıyorum Depolama | Genel | Veri alanı.
Tabii ki biraz ek yük olmalı , ancak satır başına 135 bayt özellikle büyük bir tablo için çok fazla gibi görünüyor. Bu neden olabilir? Başka benzer çarpanlar gördü mü? Gerekli olan ekstra alan miktarını hangi faktörler etkileyebilir?
Karşılaştırma için, iki INT
alan ve 1 M satır içeren bir tablo oluşturmaya çalıştım . Gereken veri alanı, 8 bayt ham veri ile karşılaştırıldığında, 16.4 MB: satır başına 17 bayt idi. Başka bir test tablosu ve gerçek tabloyla aynı metne sahip INT
bir VARCHAR(100)
nüfus tablosu, 28 artı biraz beklediğim satır başına 39 bayt (44 K satır) kullanır.
Yani üretim masasının yükü çok daha fazla. Bu daha büyük olduğu için mi? Dizin boyutlarının kabaca N * günlüğü (N) olmasını beklerdim, ancak gerçek verilerin neden doğrusal olmasının gerekli olduğunu neden anlamıyorum.
Herhangi bir işaretçi için şimdiden teşekkürler!
DÜZENLE:
Listelenen alanların tümü NOT NULL
. Gerçek tablo, bu sırada, VARCHAR
sahada ve alanda kümelenmiş bir PK'ya sahiptir DATETIME2
. İki test için birincisi INT
(kümelenmiş) PK idi.
Önemli ise: tablo ping sonuçlarının bir kaydıdır. Alanlar URL, ping tarihi / saati ve milisaniye cinsinden gecikmedir. Veriler sürekli olarak eklenir ve asla güncellenmez, ancak veriler URL başına saatte yalnızca birkaç kayda indirgemek için periyodik olarak silinir.
DÜZENLE:
Çok ilginç bir cevap burada önerir, çok okuma ve yazma ile bir dizin için, yeniden inşa yararlı olmayabilir. Benim durumumda, tüketilen alan bir endişe kaynağıdır, ancak yazma performansı daha önemliyse, gevşek endekslerle daha iyi olabilir.