Entity Framework sorgusu yavaş, ancak SqlQuery'deki aynı SQL hızlı

NET framework sürüm 4 ile Entity Framework Code-First kullanan çok basit bir sorgu ile ilgili gerçekten garip performanslar görüyorum. LINQ2Entities sorgusu şuna benzer:

 context.MyTables.Where(m => m.SomeStringProp == stringVar);

Bunun yürütülmesi 3000 milisaniyeden fazla sürer. Oluşturulan SQL çok basit görünüyor:

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = '1234567890'

Bu sorgu, Management Studio üzerinden çalıştırıldığında neredeyse anında çalışır. SqlQuery işlevini kullanmak için C # kodunu değiştirdiğimde, 5-10 milisaniye içinde çalışıyor:

 context.MyTables.SqlQuery("SELECT [Extent1].[ID] ... WHERE [Extent1].[SomeStringProp] = @param", stringVar);

Yani, tamamen aynı SQL, ortaya çıkan varlıklar her iki durumda da değişim izlenir, ancak ikisi arasında çılgın performans farkı vardır. Ne oluyor?

Buldum. Bunun SQL veri türleriyle ilgili bir sorun olduğu ortaya çıktı. SomeStringPropVeritabanında sütun varchar, ama EF NET dize türleri nvarchars varsayar. DB'nin karşılaştırmayı yapması için sorgu sırasında ortaya çıkan çeviri işlemi, uzun süren şeydir. Sanırım EF Prof beni biraz şaşırttı, çalıştırılan sorgunun daha doğru bir temsili aşağıdaki gibi olurdu:

 SELECT [Extent1].[ID], [Extent1].[SomeStringProp], [Extent1].[SomeOtherProp],
 ...
 FROM [MyTable] as [Extent1]
 WHERE [Extent1].[SomeStringProp] = N'1234567890'

Dolayısıyla, sonuçta ortaya çıkan düzeltme, doğru SQL veri türünü gösteren ilk kod modeline açıklama eklemektir:

public class MyTable
{
    ...

    [Column(TypeName="varchar")]
    public string SomeStringProp { get; set; }

    ...
}

EF'de yapılan sorgularımı yavaşlatmanın nedeni, null yapılamayan skalarları null yapılabilir skalarlarla karşılaştırmaktı:

long? userId = 10; // nullable scalar

db.Table<Document>().Where(x => x.User.Id == userId).ToList() // or userId.Value
                                ^^^^^^^^^    ^^^^^^
                                Type: long   Type: long?

Bu sorgu 35 saniye sürdü. Ancak bunun gibi küçük bir yeniden düzenleme:

long? userId = 10;
long userIdValue = userId.Value; // I've done that only for the presentation pursposes

db.Table<Document>().Where(x => x.User.Id == userIdValue).ToList()
                                ^^^^^^^^^    ^^^^^^^^^^^
                                Type: long   Type: long

inanılmaz sonuçlar verir. Tamamlanması sadece 50 ms sürdü. EF'de bir hata olması mümkündür.

Akıcı haritalamayı kullanıyorsanız IsUnicode(false), aynı etkiyi elde etmek için yapılandırmanın bir parçası olarak kullanabilirsiniz -

http://msdn.microsoft.com/en-us/data/jj591617.aspx#1.9

http://msdn.microsoft.com/en-us/library/gg696416%28v=vs.103%29.aspx

Aynı sorunu yaşadım (sorgu SQL yöneticisinden çalıştırıldığında hızlıdır) ancak EF'den çalıştırıldığında zaman aşımı sona erer.

Görünümden oluşturulan varlığın yanlış varlık anahtarlarına sahip olduğu ortaya çıktı. Yani varlık aynı anahtarlara sahip yinelenen satırlara sahipti ve sanırım arka planda gruplama yapması gerekiyordu.

Ben de karmaşık bir ef sorgusu ile karşılaştım. Benim için 6 saniyelik bir ef sorgusunu, ürettiği alt ikinci sql sorgusuna indirgeyen bir düzeltme, tembel yüklemeyi kapatmak oldu.

Bu ayarı (ef 6) bulmak için .edmx dosyasına gidin ve Özellikler -> Kod oluşturma -> Geç Yükleme Etkin'e bakın. Yanlış olarak ayarlayın.

Benim için performansta büyük gelişme.

Ben de bu sorunu yaşadım. Benim durumumdaki suçlu SQL-Server parametre koklamaktı .

Sorunumun aslında parametre koklamadan kaynaklandığına dair ilk ipucu, sorguyu "set arithabort off" veya "set arithabort on" ile çalıştırmanın Management Studio'da büyük ölçüde farklı yürütme süreleri sağlamasıydı. Bunun nedeni, ADO.NET'in varsayılan olarak "arithabort'u kapat" kullanması ve Management Studio'nun varsayılan olarak "arithabort'u açık" olarak ayarlamasıdır. Sorgu planı önbelleği, bu parametreye bağlı olarak farklı planları korur.

Burada bulabileceğiniz çözümle sorgu için sorgu planı önbelleğe almayı devre dışı bıraktım .