Varchar ve nvarchar SQL Server veri türleri arasındaki temel performans farkları nelerdir?

Okulumda küçük bir web uygulaması için bir veritabanı üzerinde çalışıyorum SQL Server 2005. Vs
konusunda birkaç düşünce okulu görüyorum :varcharnvarchar

1. varcharÇok sayıda uluslararası veriyle ilgilenmiyorsanız kullanın , sonra kullanın nvarchar.
2. nvarcharHer şey için kullanın .

2. görüşün esasını görmeye başlıyorum. Nvarchar'ın iki kat daha fazla yer kapladığını biliyorum, ancak bu sadece birkaç yüz öğrenciye veri depolayacağı için çok büyük bir anlaşma değil. Bana göre bu konuda endişelenmemek ve her şeyin nvarchar kullanmasına izin vermek en kolay yol gibi görünüyor. Yoksa özlediğim bir şey var mı?

Daima nvarchar kullanın.

Çoğu uygulama için asla çift baytlık karakterlere ihtiyacınız olmayabilir. Ancak, çift bayt dillerini desteklemeniz gerekiyorsa ve veritabanı şemanızda yalnızca tek bayt desteğiniz varsa, geri dönüp uygulamanız boyunca değişiklik yapmak gerçekten pahalıdır.

Bir uygulamayı varchar'tan nvarchar'a geçirmenin maliyeti, çoğu uygulamada kullanacağınız ek disk alanından çok daha fazla olacaktır.

Disk alanı sorun değil ... ama bellek ve performans olacak. Sayfa okumalarını iki katına çıkar, çift dizin boyutunu, garip LIKE ve = sabit davranış vb.

Çince vb script depolamak gerekiyor mu? Evet veya Hayır...

Ve MS BOL'dan " Unicode'un Depolama ve Performans Etkileri "

Düzenle :

Nvarchar performansının ne kadar kötü olabileceğini vurgulayan son SO sorusu ...

SQL Server, nvarchar dizelerinde arama yaparken yüksek CPU kullanır

Tutarlı olun! NVARCHAR'a bir VARCHAR'a katılmak büyük bir performans isabetine sahiptir.

nvarchar, bellek, depolama, çalışma kümesi ve indeksleme konusunda önemli bir yüke sahip olacak, bu yüzden teknik özellikler gerçekten gerekli olmayacağını belirtiyorsa, rahatsız etmeyin.

Ben sert ve hızlı bir "her zaman nvarchar" kural olmaz çünkü birçok durumda tam bir atık olabilir - özellikle ASCII / EBCDIC ETL veya genellikle anahtar ve yabancı anahtar olan tanımlayıcılar ve kod sütunları.

Öte yandan, bu soruyu erkenden sorduğumdan emin olabileceğim çok sayıda sütun var ve hemen sert ve hızlı bir cevap alamazsam, nvarchar sütununu yapardım.

Zaten birkaç tane daha olduğu için buraya başka bir cevap eklemekte tereddüt ediyorum, ancak ya henüz yapılmayan ya da net bir şekilde yapılmayan birkaç noktaya değinmek gerekiyor.

Birincisi: Do not her zaman kullanma NVARCHAR. Bu çok tehlikeli ve genellikle maliyetli bir tutum / yaklaşımdır. Ve bu "demek iyi değildir asla belli bir problem çözme en etkili aracı bazen, ve ortak çalışma etrafında bir yapmanın beri kullanımı imleçlerini" WHILEdöngü hemen hemen her zaman daha yavaş olacaktır düzgün yapılması İmleç.

"Her zaman" terimini kullanmanız gereken tek zaman, "her zaman durum için en iyisini yapmayı" tavsiye etmektir. Özellikle geliştirme süresindeki kısa vadeli kazançları dengelemeye çalışırken (yönetici: "şu ana kadar bilmediğiniz bir özelliğe ihtiyacımız var - bir hafta öncesine!") Belirlemek genellikle zor bir şeydir. dönem bakım maliyetleri (başlangıçta 3 aylık bir projede 3 aylık bir projeyi tamamlamak için ekibe baskı yapan yönetici: "Neden bu performans sorunları yaşıyoruz? Esnekliği olmayan X'i nasıl yapabilirdik? Ödeyemeyiz? Bunu düzeltmek için bir veya iki sprint. Öncelikli ürünlerimize geri dönebilmek için bir hafta içinde ne yapabiliriz? Ve kesinlikle tasarımda daha fazla zaman harcamamız gerekiyor, böylece bu olmaya devam etmiyor! ").

İkincisi: @ gbn'nin cevabı, yol% 100 net olmadığında belirli veri modelleme kararları verirken dikkate alınması gereken bazı önemli noktalara değiniyor. Ancak dikkate alınması gereken daha çok şey var:

• işlem günlüğü dosyalarının boyutu
• çoğaltma süresi (çoğaltma kullanılıyorsa)
• ETL'ye kadar geçen süre (ETLing ise)
• günlükleri uzak bir sisteme göndermek ve geri yüklemek için gereken süre (Günlük Gönderimi kullanılıyorsa)
• yedeklerin boyutu
• yedeklemenin tamamlanması için geçen süre
• geri yükleme yapmak için gereken süre (bu bir gün önemli olabilir ;-)
• tempdb için gerekli boyut
• tetikleyicilerin performansı (tempdb'de saklanan eklenen ve silinen tablolar için)
• satır sürüm oluşturma performansı (sürüm deposu tempdb olduğundan SNAPSHOT ISOLATION kullanılıyorsa)
• CFO, geçen yıl bir SAN'a az önce 1 milyon dolar harcadıklarını söylediğinde yeni disk alanı elde etme yeteneği ve bu nedenle ek depolama alanı için 250 bin dolar daha yetki almayacaklar
• INSERT ve UPDATE işlemlerini yapmak için gereken süre
• dizin bakımı yapmak için gereken süre
• vb, vb.

Alanın boşa harcanması , tüm sistem üzerinde büyük bir kademeli etkiye sahiptir . Bu konuda açık bir ayrıntıya giren bir makale yazdım: Disk Ucuz! ORLY? (ücretsiz kayıt gereklidir; üzgünüm bu politikayı kontrol etmiyorum).

Üçüncüsü: Bazı cevaplar yanlış bir şekilde "bu küçük bir uygulama" yönüne odaklanırken, bazıları doğru şekilde "uygun olanı kullan" ı önerirken, cevapların hiçbiri OP'ye gerçek bir rehberlik sağlamamıştır Soruda belirtilen önemli bir ayrıntı bu onların okulları için bir web sayfası olması. Harika! Yani şunu önerebiliriz:

• Öğrenci ve / veya Fakülte adları için alanlar olmalıdır muhtemelen olmak NVARCHARzamanla, sadece daha büyük olasılıkla diğer kültürlerden isimleri oralara gösterilmesini olacağını oluyor, çünkü.
• Ama sokak adresi ve şehir adları için? Uygulamanın amacı belirtilmedi (yardımcı olurdu), ancak adres kayıtlarının varsa, sadece belirli bir coğrafi bölgeye (yani tek bir dil / kültür) ait olduğunu varsayarak VARCHAR, uygun Kod Sayfası ( alanın Harmanlamasından belirlenir).
• Eyalet ve / veya Ülke ISO kodlarını saklıyorsanız ( ISO kodlarının sabit uzunluklu, insan tarafından okunabilir ve standart olduğu için INT/ depolanmasına gerek yoktur TINYINT:) CHAR(2)iki harf kodu için kullanın ve CHAR(3)3 harf kodu kullanıyorsanız. Ve gibi bir ikili Harmanlama kullanmayı düşünün Latin1_General_100_BIN2.
• Posta kodlarını (posta kodlarını) saklıyorsanız VARCHAR, AZ dışında herhangi bir harf kullanmamak uluslararası bir standart olduğu için kullanın. Ve evet, VARCHARposta kodları sayı olmadığından, dizeler olduğundan ve bazılarının önde gelen "0" ına sahip oldukları için yalnızca ABD posta kodlarını saklasanız ve INT'yi saklamasanız bile kullanın . Ve gibi bir ikili Harmanlama kullanmayı düşünün Latin1_General_100_BIN2.
• E-posta adreslerini ve / veya URL'leri saklıyorsanız, NVARCHARher ikisi de artık Unicode karakterler içerebileceğinden kullanın .
• ve bunun gibi....

Dördüncüsü: Artık, NVARCHARveriye güzelce uyan VARCHAR("güzelce uyuyor" = "?" Ye dönüşmeyen) veriler için gerekenden iki kat daha fazla yer kapladığınıza ve bir şekilde, sihirle uygulama büyüdüğü gibi ve şimdi, çoğu satırın standart ASCII olduğu ancak bazılarının Unicode karakterleri içerdiği bu alanlardan en az birinde milyonlarca kayıt var, bu nedenle saklamanız gerekiyor NVARCHAR:

1. SQL Server 2008 - 2016 RTM kullanıyorsanız ve Enterprise Edition kullanıyorsanız VEYA SQL Server 2016 SP1 (Veri Sıkıştırmayı tüm sürümlerde kullanılabilir yapan) veya daha yeni bir sürüm kullanıyorsanız, Veri Sıkıştırma'yı etkinleştirebilirsiniz . Veri Sıkıştırma, NCHARve NVARCHARalanlardaki Unicode verilerini sıkıştırabilir (ancak "her zaman" olmaz) . Belirleyici faktörler:

   1. NCHAR(1 - 4000)ve UnicodeNVARCHAR(1 - 4000) için Standart Sıkıştırma Şemasını kullanın , ancak yalnızca SQL Server 2008 R2'den başlayarak VE yalnızca IN ROW verileri için değil, OVERFLOW! Bu normal ROW / PAGE sıkıştırma algoritmasından daha iyi görünmektedir.
   2. NVARCHAR(MAX)ve XML(ve ben de tahmin VARBINARY(MAX), TEXTve NTEXT) (değil LOB veya DOLDU sayfalarında satırda kapalı) en az SAYFA sıkıştırılmış olabilir ama SIRA veriler olduğunu değil sıkıştırılmış sıra. Tabii ki, PAGE sıkıştırması satır içi değerin boyutuna bağlıdır: VARCHAR (MAX) ile test ettim ve 6000 karakter / bayt satırın sıkıştırmayacağını, ancak 4000 karakter / bayt satırın yaptığını gördüm.
   3. Herhangi bir OFF ROW verisi, LOB veya OVERLOW = Sizin İçin Sıkıştırma Yok!

2. Enterprise Edition'da değil , SQL Server 2005 veya 2008-2016 RTM kullanıyorsanız , iki alanınız olabilir: bir VARCHARve bir NVARCHAR. Örneğin, çoğunlukla tüm temel ASCII karakterleri (0 - 127 değerleri) olan ve bu nedenle VARCHARde Unicode karakterlere uyan URL'leri sakladığınızı varsayalım . Şemanız aşağıdaki 3 alanı içerebilir:

     ...
     URLa VARCHAR(2048) NULL,
     URLu NVARCHAR(2048) NULL,
     URL AS (ISNULL(CONVERT(NVARCHAR([URLa])), [URLu])),
     CONSTRAINT [CK_TableName_OneUrlMax] CHECK (
                       ([URLa] IS NOT NULL OR [URLu] IS NOT NULL)
                   AND ([URLa] IS NULL OR [URLu] IS NULL))
   );

   Bu modelde yalnızca[URL] hesaplanan sütundan SEÇ . Eklemek ve güncellemek için, dönüştürmenin gelen değeri değiştirip değiştirmediğini görerek hangi alanın kullanılacağını belirlersiniz NVARCHAR:

   INSERT INTO TableName (..., URLa, URLu)
   VALUES (...,
           IIF (CONVERT(VARCHAR(2048), @URL) = @URL, @URL, NULL),
           IIF (CONVERT(VARCHAR(2048), @URL) <> @URL, NULL, @URL)
          );

3. Gelen değerleri GZIP'e girebilir VARBINARY(MAX)ve çıkış yolundan açabilirsiniz :

   • SQL Server 2005-2014 için: SQLCLR kullanabilirsiniz. SQL # (yazdığım bir SQLCLR kütüphanesi) Ücretsiz sürümünde Util_GZip ve Util_GUnzip ile birlikte geliyor
   • SQL Server 2016 ve daha yeni sürümler için: GZip olan yerleşik COMPRESSve DECOMPRESSişlevleri kullanabilirsiniz .

4. SQL Server 2017 veya daha yenisini kullanıyorsanız, tabloyu Kümelenmiş Sütun Dizini Oluşturma konusuna bakabilirsiniz.

5. Bu henüz geçerli bir seçenek olmasa da, SQL Server 2019, UTF-8 in VARCHAR/ CHARdatatypes için yerel destek sunar . Şu anda kullanılabilmesi için çok fazla hata var, ancak düzeltildiyse, bu bazı senaryolar için bir seçenektir . Bu yeni özelliğin ayrıntılı bir analizi için lütfen " SQL Server 2019'da Yerel UTF-8 Desteği: Kurtarıcı veya Sahte Peygamber? "

Uygulamanız için, veritabanı boyutu küçük olduğundan nvarchar iyidir. "Her zaman nvarchar kullan" demek büyük bir aşırı basitleştirmedir. Kanji veya diğer çılgın karakterler gibi şeyleri saklamanız gerekmiyorsa, VARCHAR'ı kullanın, çok daha az alan kullanır. Mevcut işimdeki selefim, gerekli olmadığında NVARCHAR kullanan bir şey tasarladı. Son zamanlarda VARCHAR'a geçtik ve sadece bu tabloya 15 GB tasarruf ettik (son derece yazıldı). Ayrıca, o tabloda bir dizininiz varsa ve bu sütunu eklemek veya bileşik bir dizin oluşturmak istiyorsanız, dizin dosya boyutunuzu daha da büyüttünüz.

Kararınıza dikkat edin; SQL geliştirme ve veri tanımlarında nadiren bir "varsayılan cevap" vardır (elbette her ne pahasına olursa imleçlerden kaçınmak dışında).

Uygulamanız küçük olduğu için, nvarchar'ı varchar üzerinden kullanmanın önemli bir maliyet artışı yoktur ve unicode verilerini depolamaya ihtiyacınız varsa kendinizi potansiyel baş ağrılarından kurtarırsınız.

Genel konuşma; En az kısıtlamaya sahip en pahalı veri tipiyle başlayın. Üretime koyun . Performans sorun olmaya başlarsa, bu nvarcharsütunlarda gerçekte nelerin depolandığını öğrenin . İçeride sığmayacak karakterler var varcharmı? Değilse, varchar'a geçin. Ağrının nerede olduğunu bilmeden önceden optimize etmeye çalışmayın. Benim tahminim, nvarchar / varchar arasındaki seçimin öngörülebilir gelecekte uygulamanızı yavaşlatacak şey olmadığıdır . Performans ayarlama size dolar için çok daha fazla patlama verecek uygulamanın diğer bölümleri olacaktır .

Son birkaç yıldır tüm projelerimiz her şey için NVARCHAR'ı kullandı, çünkü tüm bu projeler çok dilli. Harici kaynaklardan içe aktarılan veriler (örn. ASCII dosyası, vb.) Veritabanına eklenmeden önce Unicode'a dönüştürülür.

Daha büyük dizinlerden, vb. Performansla ilgili herhangi bir sorunla karşılaşmadım. Dizinler daha fazla bellek kullanıyor, ancak bellek ucuz.

Saklı yordamlar kullanmak veya anında SQL oluşturmak olsun tüm dize sabitleri N (örn. SET @foo = N'Hello dünya. ';) Önek olduğundan emin olun, böylece sabit de Unicode. Bu, çalışma zamanında herhangi bir dize türü dönüştürmesini önler.

YMMV.

Bu deneyimlerden konuşabilir, sakının nvarchar. Kesinlikle istemediğiniz sürece, bu veri alanı türü daha büyük veritabanındaki performansı yok eder. Performans ve alan açısından acı çeken bir veritabanını miras aldım. 30 GB boyutundaki bir veritabanını% 70 oranında azaltabildik! Performansa yardımcı olmak için başka bazı değişiklikler yapıldı, ancak eminim varcharki bu konuda da önemli ölçüde yardımcı oldu. Veritabanınız tabloları bir milyondan fazla büyüme potansiyeline sahipse nvarcharher ne pahasına olursa olsun uzak durun .

Bu soruyu iş yerinde sık sık ele alıyorum:

• Envanter ve fiyatlandırmanın FTP beslemeleri - Varchar iyi çalıştığında öğe açıklamaları ve diğer metinler nvarchar'daydı. Bunları varchar'a dönüştürmek dosya boyutunu neredeyse yarıya indirdi ve yüklemelere gerçekten yardımcı oldu.

• Yukarıdaki senaryo, birisi ürün açıklamasına özel bir karakter koyana kadar iyi çalıştı (belki ticari marka, hatırlayamıyorum)

Varvar üzerinden her seferinde nvarchar kullanmıyorum. Özel karakterler için herhangi bir şüphe veya potansiyel varsa, nvarchar kullanıyorum. Varchar'ı en çok tarlada neyin% 100 kontrolündeyken kullandığımı görüyorum.

Bütün bu tartışmalarda neden UTF-8'den bahsedilmedi? Karakterlerin tam unicode açıklığını depolayabilmek, kişinin karakter başına iki bayt başına (veya UNICODE terimini kullanmak için "kod noktası") ayırması gerektiği anlamına gelmez. ASCII'nin tamamı UTF-8'dir. SQL Server, metnin katı ASCII (yani üst bayt biti sıfır) VARCHAR () alanlarını kontrol ediyor mu? Umarım olmaz.

O zaman unicode depolamak ve sadece eski ASCII uygulamalarıyla uyumluluk istiyorsanız, VARCHAR () ve UTF-8 kullanmanın sihirli mermi olacağını düşünürüm: Sadece gerektiğinde daha fazla alan kullanır.

UTF-8'e aşina olmayanlarınız için bir astar tavsiye edebilir miyim ?

Kasten bunu sağlamak için veri türünü kısıtlamak belirlemek istersiniz istisnai durumlar olacak gelmez belli kümesinden karakterler içerir. Örneğin, bir veritabanında etki alanı adını depolamak için gerekli bir senaryo vardı. Alan adları için uluslararasılaştırma o zaman güvenilir değildi, bu nedenle girdiyi temel düzeyde kısıtlamak ve olası sorunlardan kaçınmaya yardımcı olmak daha iyiydi.

Eğer kullanıyorsanız NVARCHARbir sistem saklı yordamı gerektiriyorsa, sırf en sık olay açıklanamaz olma sp_executesqlve dinamik SQL size tüm dize manipülasyonlar (vb birleştirme, yedek) yapıyor performans açısından daha iyi durumda olurdu, çok uzun VARCHARsonra dönüştürme sonuç NVARCHARproc parametresine verilir. Yani hayır, her zaman kullanmayın NVARCHAR!