Адаптивные соединения (Adaptive Joins) и распределение памяти в SQL Server

Автор: Kendra Little, Adaptive Joins and Memory Grants in SQL Server

Адаптивные соединения (adaptive joins) позволяют оптимизатору выбирать между хэш-соединением (Hash Join) и соединением вложенными циклами (Nested Loop join) во время выполнения, что может быть фантастически полезно для производительности, когда оценки количества строк могут варьироваться. Недавно, когда Эрик Дарлинг (Erik Darling) преподавал двухдневный курс по T-SQL на PASS Community Data Summit, один из студентов спросил, почему план запроса, в котором адаптивное соединение во время выполнения использовало вложенные циклы, всё равно получило большое распределение памяти (memory grant).

Я не помнила ответа на этот вопрос, но замечательная вещь в совместном преподавании в том, что Эрик его знал: адаптивные соединения всегда начинают выполняться как хэш-соединения, а это означает, что они должны получить распределение памяти заранее. Даже если в итоге запрос переключается на вложенные циклы во время выполнения, это распределение памяти уже было выделено. Это имеет реальные последствия для использования памяти, особенно в средах с высокой конкурентностью (high-concurrency environments).

Чего ждёт SOS_SCHEDULER_YIELD в SQL Server: причины и реакция

Автор: Steve Stedman, Decoding SOS_SCHEDULER_YIELD Wait Type in SQL Server: Causes and Solutions

Узнайте о типе ожидания SOS_SCHEDULER_YIELD в SQL Server: выявите причины, такие как конкуренция за ЦП, и найдите решения для настройки производительности с помощью экспертных советов. Этот тип ожидания возникает, когда задача добровольно уступает своё время ЦП, чтобы позволить другим задачам выполняться, что является естественной частью модели кооперативного планирования SQL Server. Однако, когда эти ожидания становятся частыми или продолжительными, они могут указывать на глубинные проблемы, ухудшающие производительность системы, что делает критически важным понимание их последствий.

По своей сути, SOS_SCHEDULER_YIELD отражает давление на ресурсы ЦП, поскольку задачи выстраиваются в очередь для выполнения. Хотя случайные уступки ожидаемы в загруженной среде, чрезмерные ожидания могут указывать на конкуренцию за ЦП, плохо оптимизированные запросы или даже аппаратные ограничения. Определение того, является ли этот тип ожидания симптомом более серьёзной проблемы, требует системного подхода к мониторингу и анализу, что в конечном итоге может привести к значительному повышению производительности.

В этой статье мы разберём тип ожидания SOS_SCHEDULER_YIELD, изучим его причины и то, когда он становится проблемой для вашей среды SQL Server. Мы проведём вас через методы диагностики, чтобы выявить корневые проблемы, и предоставим практические решения для снижения их влияния. Будь вы администратором баз данных (DBA) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.

Неудобная правда о скалярных функциях

Автор: Luca Biondi, The Dangerous Truth About Scalar Functions in 45 Seconds

Скалярные пользовательские функции (Scalar UDF) — это тихие убийцы производительности SQL Server. В этой статье я расскажу, почему они скрывают свою истинную стоимость и как превращают быстрый запрос в покадровую катастрофу.

В двух словах

• Скалярные UDF принудительно вызывают покадровое выполнение (RBAR — Row-By-Agonizing-Row): они обходят мощные алгоритмы оптимизатора, основанные на работе с наборами данных. 
• Подавление параллелизма (Parallelism): Традиционные скалярные функции заставляют весь ваш запрос выполняться в одном потоке. 
• Скрытые затраты: Планы выполнения часто показывают стоимость UDF как 0%, маскируя огромные накладные расходы на ЦП. 
• Исправление: Используйте встроенные табличные функции (Inline Table-Valued Functions, iTVF) или функцию встраивания скалярных функций (Scalar Inlining), появившуюся в SQL Server 2019+. 

Новая официальная документация о принудительной параметризации (Forced Parameterization)

Автор: Brent Ozar, New Official Documentation on Forced Parameterization

Я обожаю хорошую документацию.

Много лет я указывал людям на документацию SQL Server 2008 о принудительной параметризации (Forced Parameterization) — действительно полезном инструменте для уменьшения раздувания кэша планов, получения более точных переиспользуемых планов запросов и включения функций интеллектуальной обработки запросов (Intelligent Query Processing) SQL Server 2019 и 2022, многие из которых полагаются на один и тот же текст запроса, поступающий повторно с течением времени, чтобы настроить его. Однако эта документация была довольно скудной.

"Подводные камни" неявных преобразований

Автор: Luca Biondi, The Hidden Cost of Implicit Conversions in 45 Seconds

Неявные преобразования — это молчаливые убийцы производительности, которые превращают молниеносные поиск по индексу (Index Seek) в мучительно медленные просмотры индекса (Index Scan). В этой статье я
покажу вам, как обнаружить их за 45 секунд и вернуть ваши такты ЦП!

В двух словах

• Убийство SARGability: Неявные преобразования не позволяют SQL Server эффективно использовать поиск по индексу. 
• Накладные расходы на ЦП: Преобразование каждой строки в таблице во время сравнения значительно увеличивает использование ЦП. 
• Старшинство типов данных (Data Type Precedence): SQL Server всегда преобразует тип с более низким приоритетом в тип с более высоким. 
• Исправление: Согласуйте типы данных столбца и параметра или используйте явное приведение типов в правильном направлении. 

Бывают дни, когда я хочу бросить всё это с кэшем планов и Хранилищем запросов!

Автор: Brent Ozar, There Are Days When I Feel Like Giving Up on the Plan Cache and Query Store

В теории мониторинг производительности SQL Server довольно прост:

1. Изучите главные типы ожиданий (wait types) на сервере.
2. Найдите запросы, вызывающие эти типы ожиданий.
3. Исправьте эти запросы или улучшите реакцию сервера на них (индексы, настройки и т.д.).

Но на практике шаг 2 ужасен, потому что:

• Приложения отправляют на сервер баз данных непараметризованные строки.
• Пользователи Entity Framework строят запросы с FromSqlRaw или string.Format().
• Пользователи Entity Framework пишут запросы с .Contains, который создаёт непараметризованный список IN, даже когда ищут всего одно значение (в EF9 стало лучше).
• Люди пишут неаккуратный динамический SQL, который просто вставляет значения прямо в строку запроса.
• Разработчики SaaS-решений помещают каждого клиента в собственную базу данных, и планы не переиспользуются между базами данных.

Устранение проблем соединений с TVP

Автор: Luca Biondi, Check SQL Server TVP Join Problems in 45 Seconds ...Bad Estimates, TempDB Spills, and Parameter Sniffing | Part 17

В этой статье вы узнаете, почему соединение с Table-Valued Parameters (TVP) может разрушить вашу производительность из-за скрытых сбросов в TempDB и как это исправить с помощью надёжного, готового к проду шаблона.

🧠 В двух словах

• ✔️ Статистическая слепота: TVP не хватает статистики распределения, что заставляет оптимизатор делать зафиксированные предположения о кардинальности. 💣
• ✔️ Памятная катастрофа: Заниженные оценки количества строк приводят к недостаточному распределению памяти и массовым сбросам сортировок и хэш-операций на диск (в TempDB). 🚀
• ✔️ Ловушки sniffing'а: Кэширование планов для маленьких наборов данных в TVP приводит к полному отказу, когда позже передаются большие объёмы данных. ✔️

В высокопроизводительных SQL-средах мы полагаемся на TVP для эффективной передачи наборов данных. Но есть и тёмная сторона. Когда вы выполняете соединение (JOIN) с TVP непосредственно внутри хранимой процедуры, вы часто играете в азартную игру с исполнительным движком. Давайте разберём, почему это происходит и как сохранить контроль.

Как выбор типа данных влияет на производительность

Автор: Paul Randal, How can data-type choice affect performance?

На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.

Проверка утилизации процессоров запросами за 45 секунд: от симптомов к первопричине

Автор: Luca Biondi, Check Top CPU Queries in 45 Seconds. From Symptoms to Root Clause. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 7

Выявление высокой нагрузки на ЦП — это первый шаг; найти конкретный запрос, который спустил курок, — вот где начинается настоящая работа. В этой статье я покажу вам, как всего за 45 секунд разоблачить главных убийц ЦП в вашем кэше планов.

В двух словах

• ✔️ Время работы (Worker Time) против затраченного времени (Elapsed Time): Высокое время работы относительно продолжительности выполнения указывает на запрос, утилизирующий ЦП, или на высокий параллелизам. 
• ✔️ Анализ кэша планов (Plan Cache Mining): Используйте sys.dm_exec_query_stats, чтобы найти суммарное потребление ЦП с момента последнего перезапуска. 
• ✔️ Сосредоточьтесь на количестве выполнений: Запрос, который выполняется 1 миллион раз, потребляя по 10 мс, часто опаснее, чем запрос, выполняющийся один раз 10 секунд. 
• ✔️ Анализ первопричины: Чрезмерные сортировки, хэширование и скалярные пользовательские функции (Scalar UDF) — обычные подозреваемые в скачках ЦП. 

Проверка распределений памяти за 45 секунд: от симптомов к первопричине

Автор: Luca Biondi, Check Memory Grants in 45 Seconds. From Symptoms to Root Clause. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 6

Распределения памяти (memory grants) — это молчаливые убийцы конкурентности в SQL Server. В этой статье я покажу вам, как выявить запросы, пожирающие память, и устранить катастрофические ожидания типа RESOURCE_SEMAPHORE всего за 45 секунд — до того, как ваш сервер полностью остановится!

В двух словах

• ✔️ Распределения памяти предназначены для сортировки и хэширования: Это рабочая область оперативной памяти (workspace RAM), полностью отделённая от буферного пула, который кэширует страницы данных. 🛠️
• ✔️ Ожидания RESOURCE_SEMAPHORE: Главный красный флаг, указывающий на то, что запросы выстраиваются в очередь, испытывая голод по исполнительной памяти. 💣
• ✔️ Выявление виновников: Используйте sys.dm_exec_query_memory_grants, чтобы мгновенно обнаружить запросы, требующие непомерно больших, неоправданных объёмов оперативной памяти. 🧪
• ✔️ Устранение первопричины: В 99% случаев раздувание памяти вызвано устаревшей статистикой или плохим индексированием, а не недостатком физической оперативной памяти на сервере. ✔️

Сталкивались ли вы когда-нибудь со сценарием, когда ваш процессор практически простаивает, дисковый ввод-вывод находится в норме, но пользовательские приложения повсеместно завершаются по тайм-ауту? Добро пожаловать в ужасное узкое место RESOURCE_SEMAPHORE. Это происходит, когда ваш экземпляр исчерпывает рабочую область памяти для выполнения запросов. Давайте разберём, как диагностировать и исправлять проблемы с распределением памяти — от симптомов до первопричин — менее чем за минуту!

Миф про то, что вложенные транзакции реальны

Автор: Paul Randal, A SQL Server DBA myth a day: (26/30) nested transactions are real

Вложенные транзакции — это злое изобретение, предназначенное для того, чтобы позволить разработчикам сделать жизнь администраторов баз данных невыносимой. В SQL Server они ещё более злы…

Как не работают многоколоночные статистики

Автор: Brent Ozar, How Multi-Column Statistics Work

Короткий ответ: в реальном мире работает только первая колонка. Когда SQL Server нужны данные о второй колонке, он строит собственную статистику по этой колонке (предполагая, что она ещё не существует) и использует эти две статистики вместе — но они не коррелируют друг с другом.

SQL Server Parameter Sniffing: ошибка, которая не является ошибкой (но всё ломает)

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

В этой статье вы узнаете, как выявить и победить нестабильную производительность в SQL Server. Если ваши запросы без предупреждения переходят от «молниеносных» к «еле ползущим», вы стали жертвой Parameter Sniffing. Пришло время вернуть контроль над вашими планами выполнения и остановить непредсказуемость.

Ваш запрос работает быстро, а затем внезапно… становится медленным!
У вас есть:

• Тот же запрос.
• Те же данные.
• Тот же сервер.

👉 Что изменилось?

💣 Parameter Sniffing. И нет… это НЕ ошибка. Это то, как SQL Server был спроектирован для работы.

SQL Server Deprecated Features: 25-летняя хронология и руководство по обеспечению совместимости с будущими версиями

Автор: Steve Stedman, SQL Server Deprecated Features: A 25-Year Timeline and Future-Proofing Guide

За последние 25 лет Microsoft SQL Server значительно эволюционировал, внедряя мощные инструменты и функциональные возможности, одновременно отказываясь от других. В рамках этой эволюции многие возможности были помечены как устаревшие — они по-прежнему работают в текущих версиях, но планируются к удалению в будущих выпусках. Понимание этих устаревших возможностей имеет решающее значение для администраторов баз данных и разработчиков, чтобы обеспечить долгосрочную совместимость и избежать потенциальных сбоев в своих системах.

Объявление возможности устаревшей служит сигналом от Microsoft о необходимости перехода от устаревших или менее эффективных технологий к современным альтернативам. От изменений синтаксиса до целых компонентов — в каждой версии SQL Server появлялись возможности, которые выходили из употребления по мере адаптации платформы к новым отраслевым стандартам и потребностям пользователей. Этот непрерывный процесс помогает поддерживать надёжную, безопасную и высокопроизводительную среду баз данных, но требует проактивного планирования, чтобы избежать зависимости от инструментов, которые вскоре станут неактуальными.

В этой статье мы рассмотрим подробную хронологию устаревших возможностей в различных версиях SQL Server, начиная с SQL Server 2000 и заканчивая последними выпусками. Изучив эти изменения, вы сможете лучше подготовиться к обновлениям, реорганизовать устаревший код и принять рекомендуемые практики, чтобы сохранить вашу инфраструктуру баз данных готовой к будущему. Давайте углубимся в ключевые возможности, которые были исключены за эти годы, и разберёмся с их заменами.

Аудит заданий агента перед миграцией

Автор: Andy Brownsword, Querying msdb: A Pre-Migration Audit for SQL Agent Jobs

В большинстве заданий SQL Server, расписаний и скрытых сложностей гораздо больше, чем вы осознаёте. И только когда вы подходите к миграции и заглядываете под капот, масштаб становится очевидным.

Здесь мы извлечём детали из базы данных msdb, чтобы получить чёткое представление о том, с чем вам на самом деле предстоит иметь дело. Если вы не поймёте объём работ заранее, миграция сама выявит все сложности.

Ваш план исполнения лжёт Вам...и Вы об этом не догадываетесь

Автор: Luca Biondi, 😈 Your Execution Plan Is Lying to You ...And You Don’t Know It

уверен, что это случится с вами в какой-то момент... и с множеством ваших коллег также. Клиент сообщает вам, что ваше приложение работает крайне медленно. Вы уже идентифицировали проблемный запрос и…

Исполнение плана выглядит идеально…
но ваш запрос всё ещё медленно работает.

👉 Что-то лжёт вам.

И нет… не SQL Server! ....это то, как вы читаете план выполнения.

Десять лучших практик настройки производительности SQL Server

Автор: Paul Randal, SQL101: Top Ten SQL Server Performance Tuning Best Practices

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

Самая распространённая ошибка индексирования в SQL Server (и как её исправить)

Автор: Luca Biondi, The Most Common SQL Server Indexing Mistake (And How to Fix It)

Индексы — одна из самых мощных функций производительности в SQL Server. Но они также одни из самых непонятых. Многие разработчики считают, что добавление новых индексов автоматически улучшает производительность. К сожалению, часто бывает наоборот. Одна из самых распространённых проблем с производительностью SQL Server, которую я вижу в реальных системах, — это база данных, полная ненужных или плохо спроектированных индексов. Сегодня мы рассмотрим самую распространённую ошибку индексирования в SQL Server и способ её исправления.

Использование Claude Code с SQL Server

Автор: Brent Ozar, Using Claude Code with SQL Server and Azure SQL DB

Эта статья не для тех, кто уже использует Claude Code. Я не хочу слышать жалобы от пользователей Code в комментариях о том, что я не осветил ту или иную функцию или сценарий. Это общий обзор на ~2000 слов о том, что это такое, почему вы можете этого захотеть, что вам нужно будет обсудить с вашей командой, и куда обращаться за дополнительной информацией.

Я также должен упомянуть, что я использую множество маркированных списков в своих обычных текстах. Как и во всех моих постах, ничего из этого не написано с помощью ИИ, точка. Эти слова исходят непосредственно из моего затуманенного алкоголем мозга, написаны в марте 2026 года, и, несомненно, со временем эта информация потеряет актуальность.

Как удалось убрал 32 секунды из запроса без добавления индекса

Автор: Luca Biondi, I Removed 32 Seconds From This SQL Server Query ...Without Adding an Index! Part 7

Это не теория.
Это не лабораторная настройка.
Это произошло с реальной рабочей нагрузкой.

Исходное время выполнения: 42 секунды.
После оптимизации: 9.8 секунды.

Никакого нового индекса.
Никакого изменения схемы.
Никакого обновления оборудования.

Просто понимание того, как работает движок.

Приятного чтения — давайте заставим SQL Server летать.

Продолжение серии статей, вот предыдущая: Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)