La query di Entity Framework è lenta, ma lo stesso SQL in SqlQuery è veloce

Vedo delle prestazioni davvero strane relative a una query molto semplice utilizzando Entity Framework Code-First con .NET framework versione 4. La query LINQ2Entities ha il seguente aspetto:

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

Questa operazione richiede oltre 3000 millisecondi per l'esecuzione. L'SQL generato sembra molto semplice:

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

Questa query viene eseguita quasi istantaneamente quando viene eseguita tramite Management Studio. Quando cambio il codice C # per utilizzare la funzione SqlQuery, viene eseguito in 5-10 millisecondi:

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

Quindi, esattamente lo stesso SQL, le entità risultanti vengono tracciate in entrambi i casi, ma una differenza di prestazioni selvaggia tra i due. Cosa succede?

Trovato. Si scopre che è un problema di tipi di dati SQL. La SomeStringPropcolonna nel database era un varchar, ma EF presuppone che i tipi di stringa .NET siano nvarchar. Il processo di traduzione risultante durante la query per il DB per eseguire il confronto è ciò che richiede molto tempo. Penso che EF Prof mi abbia portato un po 'fuori strada qui, una rappresentazione più accurata della query in esecuzione sarebbe la seguente:

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

Quindi la soluzione risultante è annotare il modello code-first, indicando il tipo di dati SQL corretto:

public class MyTable
{
    ...

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

    ...
}

Il motivo per rallentare le mie query effettuate in EF era il confronto tra scalari non nullable e scalari nullable:

long? userId = 10; // nullable scalar

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

Quella query ha richiesto 35 secondi. Ma un piccolo refactoring come quello:

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

dà risultati incredibili. Ci sono voluti solo 50 ms per completare. È possibile che si tratti di un bug in EF.

Se stai usando la mappatura fluida, puoi usarla IsUnicode(false)come parte della configurazione per ottenere lo stesso effetto:

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

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

Ho avuto lo stesso problema (la query è veloce se eseguita da SQL manager) ma quando eseguita da EF il timeout scade.

Risulta che l'entità (che è stata creata dalla vista) aveva chiavi di entità sbagliate. Quindi l'entità aveva righe duplicate con le stesse chiavi e immagino che doveva fare il raggruppamento sullo sfondo.

Mi sono anche imbattuto in questo problema con una query ef complessa. Una correzione per me che ha ridotto una query ef di 6 secondi alla seconda query sql generata è stata quella di disattivare il caricamento lento.

Per trovare questa impostazione (ef 6) vai al file .edmx e guarda in Proprietà -> Generazione codice -> Caricamento lento abilitato. Impostato su falso.

Enorme miglioramento delle prestazioni per me.

Anch'io ho avuto questo problema. Si scopre che il colpevole nel mio caso era lo sniffing dei parametri di SQL-Server .

Il primo indizio che il mio problema fosse in realtà dovuto allo sniffing dei parametri era che l'esecuzione della query con "set arithabort off" o "set arithabort on" produceva tempi di esecuzione drasticamente diversi in Management Studio. Ciò è dovuto al fatto che ADO.NET utilizza per impostazione predefinita "set arithabort off" e Management Studio utilizza per impostazione predefinita "set arithabort on". La cache del piano di query mantiene piani diversi a seconda di questo parametro.

Ho disabilitato la memorizzazione nella cache del piano di query per la query, con la soluzione che puoi trovare qui .