Entity Framework 4.2 exec sp_executesql не использует индексы (анализ параметров)

Я сталкиваюсь с некоторыми серьезными проблемами производительности с простыми SQL-запросами, сгенерированными Entity Framework (4.2), работающими с SQL Server 2008 R2. В некоторых ситуациях (но не во всех) EF использует следующий синтаксис:

exec sp_executesql 'DYNAMIC-SQL-QUERY-HERE', @param1...

В других ситуациях просто выполняет необработанный SQL с предоставленными параметрами, встроенными в запрос. Проблема, с которой я сталкиваюсь, заключается в том, что запросы, выполняемые с помощью sp_executesql, игнорируют все индексы в моих целевых таблицах, что приводит к чрезвычайно низкой производительности запроса (подтверждено путем изучения плана выполнения в SSMS).

После небольшого исследования выяснилось, что проблема может быть вызвана «прослушиванием параметров». Если я добавлю подсказку запроса OPTION (RECOMPILE) следующим образом:

exec sp_executesql 'DYNAMIC-SQL-QUERY-HERE OPTION(RECOMPILE)', @param1...

Используются индексы в целевых таблицах, и запрос выполняется очень быстро. Я также попытался включить флаг трассировки, используемый для отключения анализа параметров (4136) в экземпляре базы данных ( http://support.microsoft.com/kb/980653 ), но этого не произошло. иметь какой-либо эффект.

Это оставляет мне несколько вопросов:

1. Можно ли добавить подсказку запроса OPTION (RECOMPILE) к SQL, сгенерированному Entity Framework?
2. Есть ли способ предотвратить использование Entity Framework exec sp_executesql и вместо этого просто запустите необработанный SQL?
3. Кто-нибудь еще сталкивался с этой проблемой? Есть ли другие подсказки / подсказки?

Дополнительная информация:

1. Я перезапустил экземпляр базы данных через SSMS, однако я попробую перезапустить службу из консоли управления службами.
2. Параметрирование установлено на ПРОСТОЙ (is_parameterization_ Force: 0).
3. Оптимизация для специальных рабочих нагрузок имеет следующие настройки.
   • значение: 0
   • минимум: 0
   • максимум: 1
   • value_in_use: 0
   • is_dynamic: 1
   • is_advanced: 1

Я должен также упомянуть, что если я перезапущу SQL Server Служба через консоль управления службами ПОСЛЕ включения флага трассировки 4136 с помощью приведенного ниже сценария, похоже, фактически очищает флаг трассировки ... возможно, мне следует сделать это по-другому ...

DBCC TRACEON(4136,-1)