Хранимая процедура медленнее, чем запрос LINQ?

Question

Я проводил некоторое тестирование, и прямые запросы LINQ-to-SQL выполнялись как минимум на 80% быстрее, чем при вызове хранимых процедур через запрос LINQ

В профилировщике SQL Server общий запрос LINQ

 var results = from m in _dataContext.Members
 select m;

заняло всего 19 миллисекунд, в отличие от хранимой процедуры

 var results = from m in _dataContext.GetMember(userName)
 select m;

(GetMember - хранимая процедура), выполняющий тот же запрос, который занял 100 миллисекунд

Почему это?

Edit:

Прямой LINQ выглядит так в Profiler

SELECT 
    [t1].[MemberID], [t1].[Aspnetusername], [t1].[Aspnetpassword], 
    [t1].[EmailAddr], [t1].[DateCreated], 
    [t1].[Location], [t1].[DaimokuGoal], [t1].[PreviewImageID],   
    [t1].[value] AS [LastDaimoku], 
    [t1].[value2] AS [LastNotefied], 
    [t1].[value3] AS [LastActivityDate], [t1].[IsActivated]
FROM 
    (SELECT 
         [t0].[MemberID], [t0].[Aspnetusername], [t0].[Aspnetpassword], 
         [t0].[EmailAddr], [t0].[DateCreated], [t0].[Location], 
         [t0].[DaimokuGoal], [t0].[PreviewImageID], 
         [t0].[LastDaimoku] AS [value], [t0].[LastNotefied] AS [value2], 
         [t0].[LastActivityDate] AS [value3], [t0].[IsActivated]
     FROM 
         [dbo].[Members] AS [t0]) AS [t1]
WHERE 
    [t1].[EmailAddr] = @p0

Хранимая процедура - это

SELECT Members.*
FROM Members 
WHERE dbo.Members.EmailAddr = @Username

Итак, вы видите, что запрос к хранимой процедуре намного проще ... но все же он медленнее .... не имеет смысла для меня.

Answer 1

1) Сравните как с лайком. В обоих случаях выполните одну и ту же операцию, а не извлекайте все значения в одном случае и не выполняйте запрос в другом.

2) Не выполняйте код один раз - делайте это много раз, чтобы у оптимизатора была возможность поработать и избежать единовременного снижения производительности.

3) Используйте профилировщик (ну, один на стороне .NET и один на стороне SQL), чтобы узнать, где производительность на самом деле отличается.

Answer 2

Я забыл, у proc также могут быть проблемы с прослушиванием параметров.

Answer 3

Одна вещь, которая может сделать это медленнее, это выбор *. Обычно запрос выполняется быстрее, если указаны столбцы, и, в частности, если запрос LINQ не использует все возможные столбцы в запросе, он будет выполняться быстрее, чем select *.

Answer 4

Могу ли я добавить к ответу Джона Скита, что при выполнении кода несколько раз, пожалуйста, не забудьте очистить любой кеш запросов.

Я могу предложить использовать «EXPLAIN» для обоих запросов: похоже, MySQL по-разному создает план выполнения запроса для запроса и SP. Для SP он соответствует перед заменой параметров их значениями, и поэтому он не использует индексы, которые используются в случае жестко запрограммированного или замещенного параметра. Вот еще один вопрос о различных временах выполнения для SP и прямой запрос от SO с данными плана запроса, приведенными для обоих случаев.

Answer 5

Символ * значительно увеличит время, необходимое для выполнения запроса. Кроме того, прямой SQL из LINQ, который вы видите в профилировщике, заключает в скобки ([]) все имена объектов - это сокращает время выполнения запроса LINQ.

Answer 6

В комментариях отмечается, что это не то, что вы сравниваете яблоки с яблоками. Вы пытаетесь сравнить два разных запроса, что дает разные результаты.

Если вы хотите попытаться определить производительность, вам нужно сравнить те же запросы, с теми же значениями и т. Д.

Кроме того, вы можете попробовать использовать LinqPad, чтобы увидеть сгенерированный SQL, чтобы потенциально идентифицировать области, вызывающие медленный ответ.