Запит Entity Framework повільний, але той самий SQL у SqlQuery швидкий

Question 1

Я бачу деякі справді дивні можливості, пов’язані з дуже простим запитом за допомогою Entity Framework Code-First з .NET framework версії 4. Запит LINQ2Entities виглядає так:

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

Для цього потрібно понад 3000 мілісекунд. Створений SQL виглядає дуже просто:

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

Цей запит виконується майже миттєво під час запуску через Management Studio. Коли я змінюю код C # на використання функції SqlQuery, він працює за 5-10 мілісекунд:

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

Отже, точно такий же SQL, отримані сутності відстежуються в обох випадках, але дика різниця між ними. Що дає?

Question 2

Знайшов це. Виявляється, це питання типів даних SQL. SomeStringPropСтовпець в базі даних була VARCHAR, але EF передбачає , що рядкові типи .NET є nvarchars. Отриманий процес перекладу під час запиту для БД для порівняння - це те, що займає багато часу. Я думаю, що EF Prof трохи звів мене зі шляху, точнішим поданням виконуваного запиту було б наступне:

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

Отже, отримане виправлення полягає в коментуванні першої кодової моделі із зазначенням правильного типу даних SQL:

public class MyTable
{
    ...

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

    ...
}

Question 3

Причиною уповільнення моїх запитів, зроблених у EF, було порівняння сканованих скалярів, що не допускають обнулення, та скалярів, що дозволяють обнуляти:

long? userId = 10; // nullable scalar

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

Цей запит зайняв 35 секунд. Але крихітний такий рефакторинг:

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

дає неймовірні результати. На завершення пішло лише 50 мс. Можливо, це помилка в EF.

Question 4

Якщо ви використовуєте плавне відображення, ви можете використовувати IsUnicode(false)як частину конфігурації, щоб отримати той самий ефект -

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

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

Question 5

У мене була та ж проблема (запит швидкий при виконанні з менеджера SQL), але при виконанні з EF час очікування закінчується.

Виявляється, сутність (яка була створена з подання) мала неправильні ключі сутності. Отже, сутність мала повторювані рядки з однаковими ключами, і, мабуть, для цього потрібно було групувати на задньому плані.

Question 6

Я також зіткнувся з цим із складним запитом ef. Одним із виправлень для мене, який зменшив 6-секундний запит ef до додаткового другого запиту sql, який він створив, було вимкнення лінивого завантаження.

Щоб знайти це налаштування (ef 6), перейдіть до файлу .edmx і загляньте у Властивості -> Генерація коду -> Увімкнено ліниве завантаження. Встановлено значення false.

Значне покращення продуктивності для мене.

Question 7

У мене була така проблема. Виявляється, винуватцем у моєму випадку було обнюхування параметрів SQL-сервера .

Перший підказка про те, що моя проблема насправді була пов'язана з нюханням параметрів, полягала в тому, що запуск запиту з "вимкнути arithabort вимкнено" або "встановити arithabort увімкнено" призвів до кардинально різного часу виконання в Management Studio. Це тому, що ADO.NET за замовчуванням використовує "вимкнути arithabort", а за замовчуванням Management Studio має "встановити arithabort". Кеш плану запитів зберігає різні плани залежно від цього параметра.

Я вимкнув кешування плану запитів для запиту, рішення можна знайти тут .