Entity Framework geliştiricileri için SQL'de nvarchar(max) kullanmanın tehlikeleri

Sorunu Anlamak: Entity Framework'teki Varsayılan Davranış

Tim, C# geliştiricisinin FirstName ve LastName gibi alanlarla bir model tanımladığı ortak bir Entity Framework senaryosunu anlatarak başlıyor. Tablo SQL Server'da otomatik olarak göçlerle oluşturulduğunda, üretilen şema bu dize alanlarını varsayılan olarak nvarchar(max) olarak ayarlar.

Tim'in açıkladığı gibi, bu, Entity Framework'ün atanacak uygun dize boyutunu bilmediği için, güvenli rotayı seçip varsayılan olarak maksimum uzunluğu atamayı tercih ettiği için meydana geliyor. Bu, her nvarchar sütununun 2^31–1 karaktere kadar izin verdiği, maksimum depolama boyutunun gigabaytlarca olduğu anlamına gelir.

Bu karar pratik gözükse de, tehlikeli performans maliyetlerini gizler.

İki Tablo ile Örnek Kurulum: nvarchar(max) vs Sabit Uzunluk

Sorunu vurgulamak için Tim, iki özdeş tablo oluşturur:

• Users: ad ve soyad için nvarchar(50) ile.

• UsersToTheMax: aynı alanlar için nvarchar(max) ile.

Saat 2:39'da Tim, her iki tabloyu da Dapper kullanarak 1 milyon özdeş satırla nasıl doldurduğunu anlatıyor ve sadece nvarchar veri türünün farklı olduğunu garanti ediyor.

Bu kurulum, sabit uzunluklu bir Unicode sütunu ile değişken uzunluklu max sütun arasında tutarlı bir karşılaştırma yapmasına olanak tanır.

Sorguların ve Yürütme Planlarının Karşılaştırılması

Tim her iki tabloda da şu SQL sorgusunu kullanır:

SELECT * FROM dbo.Users ORDER BY LastName;
SELECT * FROM dbo.UsersToTheMax ORDER BY LastName;

Saat 3:34'te, bu sorguları yürütürken SQL Server'ın dahili olarak ne yaptığını analiz etmek için gerçek yürütme planını etkinleştirir.

Not: Bu test makineler arasındaki toplam yürütme süresi hakkında değil—Tim, nvarchar(max)'in performansı nasıl etkilediğini izole etmek için aynı sunucuda ve aynı veri ile sorguları karşılaştırmayı vurguluyor.

Şok Edici Sonuçlar

Yürütme planları büyük bir fark gösterir:

• nvarchar(50) üzerindeki sorgu toplu işlem maliyetinin sadece %2'sini kullanır.

• nvarchar(max) üzerindeki sorgu ezici bir şekilde maliyetin %98'ini kullanır.

Tim'in belirttiği gibi, bu, max sorgusunun SQL Server'ın nasıl işlediği açısından 50 kat daha pahalı olması anlamına gelir—sütun veri girişleri aynı ve nispeten küçük olmasına rağmen.

CPU zamanına göre:

• nvarchar(50) sıralamak 107ms sürer.

• nvarchar(max) sıralamak 339ms sürer.

Fakat en büyük fark belirli bir paralellik işlemdir:

• Sabit uzunluk: 0.43s

• Maksimum uzunluk: 22.17s

Bu, aynı veri ile 50 kat daha yavaş.

Bellek Tüketimi Farklılıkları

Tim bellek izinlerine—SQL Server'ın her sorgu için ne kadar bellek ayırdığına—dalar:

• nvarchar(50) sorgusu: 340MB

• nvarchar(max) sorgusu: 641MB

Bu tek başına bir uyarı işaretidir, ancak önbelleğe alınmamış sütunları test ederken etki daha da dramatiktir:

• FirstName üzerinde sabit uzunluk: 357MB

• FirstName üzerinde maksimum uzunluk: 8.5GB

Bu artış, nvarchar değeri max olarak tanımlandığında SQL Server'ın ne kadar büyük olabileceğini bilmediği için meydana gelir, bu nedenle maksimum boyutu karşılamak için daha büyük bir bellek bloğu ayırır.

Neden nvarchar(max) Bu Kadar Pahalı?

Saat 9:15'te Tim altta yatan nedeni açıklar. nvarchar(max) veri türü:

• 2^31–1 Unicode karaktere kadar destekler, 2GB'a kadar depolama alanı tüketir.

• Eğer sığmazsa değeri satır dışında saklaması gerekir, doğrudan satır içi depolama yerine bir gösterici kullanır.

• Sabit uzunluklu sütunlar gibi indekslenemez.

Sonuç olarak:

• nvarchar(max) sütununu indeksleyemezsiniz, bu da SQL Server'ın tam veri setini optimizasyon olmadan sıralaması veya filtrelemesi gerektiği anlamına gelir.

• Bu, ORDER BY, WHERE veya JOINs gibi işlemleri nvarchar(max) alanlarında etkiler.

Bu davranış, sadece yanlış karakter veri uzunluğunu seçmekten dolayı önemli bellek kullanımı, CPU yükü ve yavaşlamalara yol açar.

Tim'in Son Tavsiyesi

Tim'in kapanışta söylediği gibi:

"Entity Framework sorgularınızda, tüm dizelerin boyutunu belirttiğinizden emin olun."

Dize özelliklerinizi, beklenen verilere bağlı olarak nvarchar(100) veya nvarchar(255) gibi maksimum karakter sayısıyla her zaman tanımlayın. Bu küçük değişiklik şunları garanti eder:

• Optimizasyonu sağlanmış depolama alanı

• İndeksleme desteği

• Azalmış sorgu maliyeti

• Daha iyi performans tutarlılığı

Uygun bir uzunluk belirleyerek, veritabanı şemanızı daha verimli hale getirir ve tembel varsayılan ayarların tuzaklarından kaçınırsınız.

Sonuç

Tim Corey'nin videosu kritik bir ders verir: SQL'de dize alanları için varsayılan uzunluk olarak nvarchar(max) kullanmak performansı sessizce felç edebilir. SQL Server gereksiz bellek tüketir, dizinleri atlar ve isimler ya da adresler gibi sıradan Unicode metin girişleri için bile CPU maliyetlerini artırır.

Çıkarım? nvarchar veri türünü anlamak ve sadece büyük belgeler veya değişken uzunluklu içerik saklayabilecek alanlar için max kullanmaktan kaçının.

Dize boyutunu belirtmek, yalnızca baytları ve belleği tasarruf etmenizi sağlamaz—aynı zamanda Entity Framework ve SQL kodunuzu daha verimli, ölçeklenebilir ve sağlam hale getirir. Tim'in rehberliğini takip ederek, uygulamanızın tasarım gereği yavaş olmadığını sağlarsınız.

.NET'te veritabanları ile çalışan herkes için bu, standart araç setinizin bir parçası olması gereken bir en iyi uygulamadır. Daha fazla SQL ile ilgili video için Tim'in Kanalına göz atın.