Когда я читаю различные форумы о SQL Server, я часто вижу вопросы от глубоко озадаченных авторов. Они обнаружили в своем приложении медленный запрос или медленную хранимую процедуру. Они берут пакет SQL из приложения и запускают его в SQL Server Management Studio (SSMS) для анализа, но обнаруживают, что ответ мгновенный. На данный момент они склонны думать, что SQL Server — это волшебство. Аналогичная загадка возникает, когда разработчик извлекает запрос из своей хранимой процедуры, чтобы запустить его автономно, но обнаруживает, что он выполняется намного быстрее или намного медленнее, чем внутри процедуры.

Нет, SQL Server — это не магия. Но если вы плохо понимаете, как SQL Server компилирует запросы и поддерживает кэш планов, может показаться, что это так. Кроме того, существуют неудачные комбинации разных значений по умолчанию в разных средах. В этой статье я попытаюсь объяснить, почему у вас такое, казалось бы, непоследовательное поведение. Я объясню, как SQL Server компилирует хранимую процедуру, что такое перехват параметров и почему он является частью уравнения в подавляющем большинстве этих запутанных ситуаций. Я объясню, как SQL Server использует кеш и почему в кеше может быть несколько записей для процедуры. Зайдя так далеко, вы поймете, почему запрос в SSMS выполняется намного быстрее.

Чтобы понять, как решить эту проблему с производительностью в вашем приложении, вам нужно читать дальше. Сначала я немного отвлекусь от темы перехвата параметров, чтобы обсудить несколько ситуаций, в которых есть другие причины разницы в производительности. Далее следуют две главы о том, как справляться с проблемами производительности, связанными с перехватом параметров. Первый связан со сбором информации. Во второй главе я обсуждаю некоторые сценарии — как реальные ситуации, с которыми я столкнулся, так и более общие — и возможные решения. Далее следует глава, в которой я расскажу, как динамический SQL компилируется и взаимодействует с кэшем планов, а также почему существует больше причин, по которым вы можете столкнуться с различиями в производительности между SSMS и приложением с динамическим SQL. В последней главе я расскажу, как вы можете использовать Query Store — функцию, представленную в SQL 2016 для устранения неполадок. В конце есть раздел со ссылками на официальные документы Microsoft и аналогичные документы в этой области.