Есть ли способ реализовать запрос с TSQL Option в Entity Framework

У нас есть один запрос, который работает с очень низкой скоростью.

Но он начинает летать, если мы добавим предложение OPTION в запрос. Как это:

select distinct 
    d.* 
from 
    Bundles b, 
    Bundles_Permissions bp, 
    CameraGroupPermissions cgp, 
    Addresses a, 
    Districts d, 
    Cameras c, 
    Cameras_CameraGroups ccg 
where 
    b.Id = bp.BundleId 
    and bp.CameraGroupPermissionId = cgp.Id 
    and cgp.ShortName = 'See-Cameras' 
    and b.CameraGroupId = ccg.CameraGroupId 
    and ccg.CameraId = c.Id 
    and b.UserGroupId = ''
    and c.AddressId = a.Id 
    and c.CameraStateId in (5,3,4,9) 
    and c.IsDeleted = 0 
    and d.Id = a.DistrictId 
    OPTION (HASH JOIN) 

Вопрос заключается в том, как заставить Entity Framework добавить этот OPTION в конец сгенерированного запроса?

Пока мы используем хранимые процедуры, чтобы он работал, но это не похоже на хорошее решение.

  1. Мы освобождаем все возможности, предоставляемые нам IQueryable .
  2. Вся логика запроса/выбора хранится в нашем приложении, но эту часть мы должны хранить в базе данных.

UPDATE (пример медленного запроса linq2Entity):

camsResult = from permis in ((MoscowVideoDbEntities) ObjectContext).CameraGroupPermissions
                             where permis.ShortName == Permissions.CameraGroupSpecific.SeeCameraVideo
                             from bundles in permis.Bundles
                             where bundles.UserGroupId == user.UserGroupId
                             from cams in bundles.CameraGroup.Cameras
                             where
                                 !cams.IsDeleted
                                 && (
                                        cams.CameraStateId == (int) CameraStates.InExploitation ||
                                        cams.CameraStateId == (int) CameraStates.OnVerification ||
                                        cams.CameraStateId == (int) CameraStates.Rejected ||
                                        cams.CameraStateId == (int) CameraStates.OnMaintenance
                                    )
                                 && cams.Address != null
                             select cams;

var result = (from cams in camsResult 
    from districts in ((MoscowVideoDbEntities)ObjectContext).Districts 
    where districts.Id == cams.Address.DistrictId 
    select districts).Distinct().ToList(); 
2
nl ja de
Плохие привычки к удару: используя JOIN в старом стиле - стиль стиля таблиц , разделенных запятыми, был прерван с помощью стандартного стандарта ANSI <<>> </>> ANSI < 20 лет назад!). Пожалуйста, прекратите использовать его
добавлено автор marc_s, источник
2Hamlet: Хорошо, я добавлю linq-запрос немного позже, но я не могу понять, как он может вам помочь) 2marc_s: вопрос не в стиле sql-запроса, а в tnx для вашего беспокойства
добавлено автор Pavel Luzhetskiy, источник
@Yugz вот как мы его готовим сейчас. Я упомянул, почему хранимое proc выглядит плохое решение, о котором идет речь выше. Тем не менее, это то, как мы это делаем сейчас.
добавлено автор Pavel Luzhetskiy, источник
Вы хотите сказать, что запрос генерируется linq2entity? Если да, то макет переформатирует ваш запрос. Предоставьте свой linq, пожалуйста.
добавлено автор Hamlet Hakobyan, источник
В чем проблема с запросом в сохраненном процессе? вы получите гораздо лучшую производительность, выполняя свой запрос из хранимой процедуры по сравнению с использованием linq
добавлено автор Yugz, источник
Ok Cool ... удачи в поиске решения
добавлено автор Yugz, источник

1 ответы

If you can get the Entity Framework to submit the query as prepared SQL (which you should anyway) you can use a plan-guide to change the execution plan for this query: http://msdn.microsoft.com/en-us/library/ms190417(v=sql.90).aspx

Однако использование подсказок подсказок всегда должно быть последним. Вместо того, чтобы форсировать хеш-соединение во всех шести операциях объединения в этом запросе, что эффективно отключает оптимизатор, вы можете посмотреть другие параметры, такие как правильная индексация и правильная поддерживаемая статистика.

2
добавлено
Tnx. Я посмотрю более глубоко в ваш ответ =)
добавлено автор Pavel Luzhetskiy, источник
Tottaly соглашается с тем, что «попробуйте не использовать подсказки», но у нас действительно есть какая-то магия, связанная с этим запросом. Мы должны копировать базу данных, работающая отлично, только с OPTION. Нет тотальной разницы в индексировании или каких-либо других видимых изменениях. Но план выполнения выглядит совершенно по-другому. Мы не можем воспроизвести, как улучшить выполнение, поэтому решение всегда ставить OPTION было сделано.
добавлено автор Pavel Luzhetskiy, источник
SqlCom.ru - Стиль жизни SQL
SqlCom.ru - Стиль жизни SQL
908 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только MS SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz). Предложения в @sql_ninja

SQL_Ninja
SQL_Ninja
340 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz)