Entity Framework zapytanie powolne, ale ten sam SQL w SqlQuery jest szybki

Question

Widzę kilka naprawdę dziwnych perf związanych z bardzo prostym zapytaniem przy użyciu Entity Framework Code-First z platformą .NET 4. Wersja LINQ2Entities wygląda następująco:

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

Zajmuje to 3000 milisekund do wykonania. Wygenerowany kod SQL wygląda bardzo prosto:

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

To zapytanie działa niemal natychmiast po uruchomieniu za pomocą Management Studio. Kiedy zmienić kod C#, aby korzystać z funkcji sqlquery, działa w 5-10 milisekund:

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

Tak, dokładnie ten sam SQL, wynikające z istoty są śledzone zmiany w obu przypadkach, ale dziki różnica między perf dwa. Co daje?

Answer 1

Znaleziono. Okazuje się, że jest to kwestia typów danych SQL. Kolumna SomeStringProp w bazie danych była varcharem, ale EF zakłada, że ​​typy łańcuchów .NET to nvarchary. Wynikowy proces tłumaczenia podczas kwerendy dla DB, aby dokonać porównania, zajmuje dużo czasu. Myślę EF Prof prowadził mnie na manowce trochę tu, dokładniejsze przedstawienie zapytania jest prowadzony byłby następujący:

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

Tak otrzymany poprawka jest do opisywania modelu kodu pierwszego, wskazując poprawną SQL Typ danych:

public class MyTable 
{ 
    ... 

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

    ... 
} 

Answer 2

miałem ten sam problem (kwerenda jest szybki, gdy wykonywane z menedżerem SQL), ale gdy są wykonywane z EF upłynie czas.

Okazuje się, że encja (która została utworzona z widoku) miała niepoprawne klucze encji. Tak więc istota miała zduplikowane wiersze z tymi samymi kluczami i myślę, że musiała robić grupowanie w tle.

Answer 3

Jeśli używasz biegle mapowanie, można użyć IsUnicode(false) jako część konfiguracji, aby uzyskać ten sam efekt -

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

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

Answer 4

doszedłem również po drugiej stronie to z kompleksem zapytanie ef. Jedną z poprawek dla mnie, która zmniejszyła 6 sekundową kwerendę ef do kwerendy drugiej sekundy sql, która została wygenerowana, było wyłączenie leniwego ładowania.

Aby znaleźć to ustawienie (ef 6), przejdź do pliku .edmx i sprawdź Właściwości -> Generowanie kodu -> Włączono ładowanie Lazy. Ustaw na false.

Ogromna poprawa wydajności dla mnie.

Answer 5

Przyczyną spowolnienia moje pytania skierowane w EF porównywał pustych skalary z pustych skalarów:

long? userId = 10; // nullable scalar 

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

To zapytanie trwało 35 sekund. Ale malutki refaktoryzacja:

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 

daje niesamowite rezultaty. Trwało to tylko 50ms. Możliwe, że jest to błąd w EF.

Answer 6

Możesz używać następujących sztuczki, aby zapiąć zapytań -

1. Ustawic ctx.Configuration.ProxyCreationEnabled do false tuż przed dostać kontekst.
2. Również, .Select(c => new {c.someproperty}) pobierze tylko wymagane dane, a nie całą wiązkę.

Daj mi znać, jeśli to pomogło.

Answer 7

Miałem również ten problem. Okazuje się, że winowajcą w moim przypadku było wyczuwanie parametrów SQL-Server. Read more.

Pierwszą wskazówką, że moim problemem było w rzeczywistości ze względu na wąchanie parametrów było to, że uruchomienie zapytania z "set arithabort off" lub "set arithabort on" spowodowało drastycznie inne czasy wykonania w Management Studio. Dzieje się tak dlatego, że domyślnie ADO.NET używa "set arithabort off", a Management Studio domyślnie "ustawia arithabort on", a cache planu zapytań utrzymuje różne plany w zależności od tego parametru.

I wyłączono buforowanie planu kwerend dla zapytania, z rozwiązaniem można znaleźć here.