Uzun sütunlar performansı ve disk kullanımını nasıl etkiler?

Mevcut projemizde, çok sık gerçekleşir, sütunların birkaç karakter uzatılması gerekir. Gönderen varchar(20)etmek varchar(30)ve bu kadar.

Gerçekte, bunun ne kadar önemi var? Bu ne kadar iyi optimize edilmiştir? Normal "giriş" alanları için sadece 100 veya 200 veya hatta 500 karaktere izin vermenin etkisi nedir? Bir e-posta yalnızca 320 karaktere sahip olabilir, o yüzden tamam - orada iyi bir sınır var. Fakat 200'e ayarlarsam ne kazanacağım, çünkü bundan daha uzun e-posta adresleri beklemiyorum.

Genellikle masalarımızda 100.000'den fazla satır ve 20 veya 30'a kadar sütun bulunmaz.

Şimdi SQL Server 2008 kullanıyoruz, ancak farklı DB'lerin bu sorunları nasıl ele aldığını bilmek ilginç olurdu.

Etkinin çok düşük olması durumunda - beklediğim gibi, bu uzun-alan-paranoya'nın gerçekten gerekli olmadığına DBA'mı ikna etmek için bazı iyi argümanlar (bağlantılar ile desteklenmiş mi?) Elde etmek yardımcı olacaktır.

Bu durumda, öğrenmek için buradayım :-)

Sorunuza verilen spesifik cevap (en azından Oracle ve muhtemelen diğer veritabanları için), alanın uzunluğunun önemli değil, yalnızca verilerin uzunluğudur. Ancak, bu alanın izin verilen maksimum uzunluğa ayarlanıp ayarlanmamasına ilişkin belirleyici bir faktör olarak kullanılmamalıdır. Alan boyutlarını maksimize etmeden önce göz önünde bulundurmanız gereken bazı diğer hususlar.

Biçimlendirme Verileri alanların boyutuna göre biçimlendiren herhangi bir istemci aracı özel biçimlendirme hususları gerektirecektir. Oracle SQL * Plus, örneğin, varsayılan olarak, veriler yalnızca bir karakter uzunluğunda olsa bile, maksimum Varchar2 sütunlarının boyutunu görüntüler. Karşılaştırmak…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Kötü Veri Alan uzunluğu, kötü verileri yakalamak / önlemek için ek bir mekanizma sağlar. Bir arabirim 100 karakterlik bir alana 3000 karakter eklemek istememelidir, ancak bu alan 4000 karakter olarak tanımlandıysa, sadece olabilir. Hatanın veri giriş aşamasında yakalanmaması gerekir, ancak başka bir uygulama verileri işlemeye çalıştığında ve tıkandığında, sistemin daha da zorlanmasına neden olabilir. Örnek olarak, daha sonra Oracle'da alanı endekslemeye karar verirseniz, maksimum anahtar uzunluğunu aşmış olursunuz (blok büyüklüğüne ve birleştirmeye bağlı olarak). Görmek…

create index i1 on f1(a);

Bellek İstemci uygulaması maksimum boyutu kullanarak bellek ayırırsa, uygulama gerektiğinden çok daha fazla bellek tahsis eder. Bundan kaçınmak için özel hususların yapılması gerekecektir.

Dokümantasyon Alanın boyutu, verilerle ilgili başka bir dokümantasyon veri noktası sağlar. Tüm tablolara t1, t2, t3, vb. Ve tüm alanları f1, f2, f3, vb. Çağırabiliriz, ancak anlamlı isimler belirterek verileri daha iyi anlarız. Örneğin, ABD’deki müşterileri olan bir şirketin adres tablosu Devlet olarak adlandırılan bir alana sahipse, iki karakterlik durum kısaltmasının içeri girmesini bekleriz. Öte yandan, alan yüz karakter ise, tam durum adının alana girmesini bekleyebiliriz.

Bütün bunlar söylendiğinde değişime hazırlıklı olmak akıllıca görünmektedir. Günümüzde tüm ürün isimlerinizin 20 karaktere uyması, her zaman alacağı anlamına gelmez. Denize düşüp 1000 yapmayın, ancak makul genişleme için yer bırakın.

İşte sizin için iyi bir başlangıç ​​noktası.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Asıl sorunuzu yanlış anlamış olabilirim. Bakalım referans için birkaç bağlantı bulabilir miyim?

Veri türü seçimleri için iyi referans: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Varchar (20) 'den varchar (30)' a değiştirmek küçük bir şey gibi görünebilir, ancak potansiyel sorunların farkında olmak için veritabanı yapılarının nasıl çalıştığı hakkında daha fazla bilgi sahibi olmanız gerekir. Örneğin, varchar (30) 'a gitmek, bir sayfada (8060 bayttan daha az) bir sayfada saklanabilmek için sütunlarınızın uç noktasının (30 baytın tümü kullanıldığında) üzerine itmesine neden olabilir. Bu, kullanılan disk alanında bir artışa, performansta bir düşüşe ve hatta işlem kayıtlarınızla birlikte bazı ek masraflara neden olacaktır.

İşte veritabanı yapıları için bir link: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Sayfa bölmeleri ve trx günlüğü için bir tane: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

Aşağıdaki SO soruda bulduğum başka bir ilginç noktayı paylaşacağımı düşündüm:

https://stackoverflow.com/questions/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

Orijinal cevap: Nick Kavadias

Max veya text alanlarını kullanmamanın bir nedeni [online index rebuilds] [1] yapamamanızdır; yani, SQL Server Enterprise Edition ile bile ONLINE = REBUILD = ON.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "çevrimiçi dizin yeniden oluşturulur"

Keyfi olarak n / varchar (max) sütunlarını eklerken bunun büyük bir dezavantaj olduğunu düşünmekteyim ve MS Sitesine göre çevrimiçi indeks yeniden oluşturmalarına karşı bu kısıtlama SQL Server 2008, 2008 R2 ve Denali'de kalıyor; bu yüzden SQL Server 2005'e özgü değil.

Teşekkürler Jeff

Bazı durumlarda, varchar alanı için ayırdığınız alan miktarı, bellek içi sıralar için ayrılan bellek miktarını etkiler.

Sunumları düşünen SQLWorkshops.com adresindeki sunumları buldum, bu sunum, bir sipariş için bir sıralamanın tempdb'ye döküleceği bir durum hakkında konuşuyor çünkü char / varchar alanları için yeterli bellek ayrılmıyor.

http://webcasts2.sqlworkshops.com/webcasts.asp

Bu web yayını aşağıdaki web sitesinde de bir makale olarak sunulmuştur:

http://www.mssqltips.com/tip.asp?tip=1955

Bu sunumda, sıralanan sütunun char / varchar sütunu olmadığını, ancak bellekteki varchar sütunu için ayrılan alan miktarının bazı durumlarda sorgu performansında fark yarattığını unutmayın.

ANSI_PADDING AÇIK mı?

Sonunda birçok boşluk var ...

Yalnızca disk alanı ve karakter uzunluğu ile ilgilidir. Elbette char veri tiplerinde ve bu tip veri üzerinde indekslerde arama yapmak tamsayıdan daha yavaş hareket edecektir, fakat bu başka bir tartışma.

Varchar veri türü bir "değişken" veri türüdür; bu nedenle, bu alanın maksimum karakter uzunluğundan daha büyük bir varchar (500) limiti ayarlarsanız. Minimum uzunluk 0 ile 500 arasında olabilir. Öte yandan, talep edilen disk alanı 10, 30 veya 500 karakter alanı için farklı olacaktır.

Bazen veri tipi varchar (800) için bir test yaptım ve boş değerler için 17 bayt kullandım ve eklenen her karakter için bir bayt daha ekledi. Örneğin, 400 karakterlik bir dizgede diskte kullanılan 417 bayt vardı.

Gerçek maksimum uzunluk <= 20 olduğu sürece, varchar (20) veya varchar ((8000) sütunlarıyla oluşturulan tablolar arasında bir fark olduğunu sanmıyorum.

Diğer taraftan, bazı durumlarda kullanıcılara daha uzun dizeler kaydetme imkanı verilmesi onları yapmalarını teşvik edebilir.