Наше приложение использует драйвер sql .net, и запросы в профилировщике выглядят примерно так:
sp_executesql N'query where @param = ?, and param2 = ?', param, param2, param3, etc
При копировании и вставке запроса из Profiler в студию управления сервером sql запрос будет выполняться менее чем за минуту по сравнению с 15-20 минутами выполнения из приложения.
Насколько я могу судить, они оба используют один и тот же план выполнения, поэтому я не уверен, что будет по-другому.
Чтобы добавить странности, у нас также есть тестовый сервер sql, который по сути является копией рабочего сервера. В нашей тестовой среде с тем же кодом и в основном с теми же данными (несколько дней с момента выпуска) запрос выполняется менее чем за минуту в нашем приложении, а также в студии управления сервером sql. Опять же, профилировщик фиксирует один и тот же план выполнения для всех из них.
Единственное, что я обнаружил, заставляет запрос выполняться правильно - это запуск процедуры sp_updatestats в базе данных, которую мы запускаем каждое утро в 5:00. Что странно, к 7:00 запрос снова будет работать медленно. Если я снова запустил sp_updatestats, запрос завершится менее чем за минуту. И снова все планы выполнения выглядят одинаково.
Я, должно быть, что-то упускаю. Любые идеи?
Включает ли ваш запрос таблицу с восходящим столбцом datetime или datetime2, и одним из параметров является datetime или datetime2, который обычно ищет последнее значение?
Ваши комментарии относительно поведения после обновления статистики говорят о том, что вы столкнулись с проблемой часто устаревшей статистики, которую Гейл Шоу описывает здесь: http://sqlserverpedia.com/blog/sql-server-bloggers/statistics-row-estimations-and-the-ascending-date-column/
Как отмечает Гейл, наиболее простым решением является более частое обновление статистики. В идеале ориентируйтесь на те более частые обновления статистики, которые в них нуждаются - см. Обновить статистику.
В случае очень больших таблиц также может быть полезен отфильтрованный индекс, в зависимости от размера таблицы и шаблонов обновления и чтения.
Сейчас я пытаюсь улучшить свои навыки SQL, так что отнеситесь к этому с недоверием. Но, возможно, это Анализ параметров проблема ?:
Анализ параметров - это процесс, посредством которого SQL Server создает оптимальный план для хранимой процедуры с использованием параметров вызова, которые передаются при первом выполнении хранимой процедуры. Под «первым разом» я на самом деле имею в виду всякий раз, когда SQL Server вынужден скомпилировать или перекомпилировать хранимые процедуры, потому что их нет в кэше процедур. Каждый последующий вызов одной и той же процедуры хранилища с теми же параметрами также будет получать оптимальный план, тогда как вызовы с разными значениями параметров не всегда могут получить оптимальный план.
- http://www.simple-talk.com/sql/t-sql-programming/parameter-sniffing/
Как я уже сказал в своем заявлении об отказе от ответственности, мне нужно многому здесь научиться, но если я правильно это понимаю, если это так, я думаю, что если вы пройдете OPTION RECOMPILE на запрос, и проблема исчезнет, возможно, это была ваша проблема.