Автор: SomewhereSomehow
Давненько я хотел написать что-нибудь на эту тему. Однако, пока я собирался с мыслями и силами, наткнулся на уже написанную статью Slow in the Application, Fast in SSMS? Understanding Performance Mysteries Erland-а Sommarskog, которая исчерпывающе отвечает на поставленный вопрос. Так что мне осталось только представить перевод этой статьи, который я для удобства разделил на три части.
Введение
Когда я просматриваю различные форумы по SQL Server, я часто вижу вопросы от глубоко озадаченных пользователей. Они нашли медленный запрос или процедуру в своем приложении. Переместили этот пакет из своего приложения в SQL Server Management Studio (SSMS), чтобы проанализировать и обнаружили, что ответ от сервера приходит мгновенно. С этого момента они начинают думать что SQL Server это нечто магическое. Похожая загадка происходит и в случае если разработчик извлекает запрос из своей хранимой процедуры, чтобы выполнить его отдельно, но обнаруживает что он выполняется гораздо быстрее - или гораздо медленнее - чем внутри хранимой процедуры.
Нет, SQL Server это не магия. Но если у вас нет хорошего понимания того как SQL Server компилирует запросы и поддерживает кэш планов выполнения, так может показаться. Кроме того есть некоторые неудачные комбинации различных настроек по умолчанию в некоторых средах. В этой статье я постараюсь разъяснить, почему вы получаете такое, казалось бы, не согласующееся поведение. Я объясню, как sql server компилирует хранимую процедуру, что такое прослушивание параметров (parameter sniffing) и почему оно является важной частью уравнения в большинстве сбивающих с толку ситуаций. Я объясню, как sql server использует кэш, и почему в кэше может быть несколько записей для одной процедуры. Стоит только копнуть глубже, и вы поймете, как получается так, что запрос в SSMS выполняется гораздо быстрее.
читать дальше...
Введение
Когда я просматриваю различные форумы по SQL Server, я часто вижу вопросы от глубоко озадаченных пользователей. Они нашли медленный запрос или процедуру в своем приложении. Переместили этот пакет из своего приложения в SQL Server Management Studio (SSMS), чтобы проанализировать и обнаружили, что ответ от сервера приходит мгновенно. С этого момента они начинают думать что SQL Server это нечто магическое. Похожая загадка происходит и в случае если разработчик извлекает запрос из своей хранимой процедуры, чтобы выполнить его отдельно, но обнаруживает что он выполняется гораздо быстрее - или гораздо медленнее - чем внутри хранимой процедуры.
Нет, SQL Server это не магия. Но если у вас нет хорошего понимания того как SQL Server компилирует запросы и поддерживает кэш планов выполнения, так может показаться. Кроме того есть некоторые неудачные комбинации различных настроек по умолчанию в некоторых средах. В этой статье я постараюсь разъяснить, почему вы получаете такое, казалось бы, не согласующееся поведение. Я объясню, как sql server компилирует хранимую процедуру, что такое прослушивание параметров (parameter sniffing) и почему оно является важной частью уравнения в большинстве сбивающих с толку ситуаций. Я объясню, как sql server использует кэш, и почему в кэше может быть несколько записей для одной процедуры. Стоит только копнуть глубже, и вы поймете, как получается так, что запрос в SSMS выполняется гораздо быстрее.
читать дальше...
Комментарии
Скажите как объяснить, что при выполнении
EXEC List_orders_4 '20000101' (Index Seek + Key LookUp)
EXEC List_orders_4 (Clustered Index Scan)
Дает разные планы, т.е. '19900101' прослушивается?
CREATE PROCEDURE [dbo].[List_orders_4] @fromdate datetime = null AS
IF @fromdate IS NULL
SELECT @fromdate = '19900101'
SELECT * FROM Orders WHERE OrderDate > @fromdate
OPTION(RECOMPILE)
Прослушивается, потому что вы указали OPTION(RECOMPILE). Читайте дальше, там по поводу OPTION(RECOMPILE) даны разъяснения: "Один очень простой вариант, но с некоторыми ограничениями, это добавить OPTION (RECOMPILE) в конец запроса..." и т.д.