19.5.26

Чего ждёт 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) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.

18.5.26

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


Автор: 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+. 

17.5.26

Клонирование с помощью аварийно-устойчивых снимков в Hyper-V


Автор: Anthony Nocentino, Crash-Consistent Snapshot Cloning - Hyper-V Edition

Если вы следили за моей серией статей о резервном копировании через снимки с помощью T-SQL (T-SQL Snapshot Backup), то большая часть из того, о чём я рассказывал, требовала участия SQL Server в создании снимка: заморозка операций записи, резервное копирование метаданных, скоординированный рабочий процесс. Эта статья покрывает другую сторону этого вопроса: клонирование, устойчивое к аварийному отказу (crash-consistent cloning). Никакой заморозки записи. Никакого резервного копирования. Никакого восстановления на момент времени. Просто клон тома «сырых» данных, который SQL Server автоматически восстанавливает при подключении.

15.5.26

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


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

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

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

14.5.26

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


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

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

В двух словах

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

13.5.26

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

Автор: 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-решений помещают каждого клиента в собственную базу данных, и планы не переиспользуются между базами данных.

Исправление безопасности для SQL Server 2025 CU4 - KB5089899

Описание: KB5089899

Скачать: SQLServer2025-KB5089899-x64.exe

Дата выпуска: 12.05.2026

SQL Server 2022 — Версия: 17.0.4040.1

Исправление безопасности для SQL Server 2025 GDR - KB5091223

Описание: KB5091223

Скачать: SQLServer2025-KB5091223-x64.exe

Дата выпуска: 12.05.2026

SQL Server 2022 — Версия: 17.0.1115.1

Исправление безопасности для SQL Server 2022 CU24 - KB5089900

Описание: KB5089900

Скачать: SQLServer2022-KB5089900-x64.exe

Дата выпуска: 12.05.2026

SQL Server 2022 — Версия: 16.0.4252.3

Исправление безопасности для SQL Server 2022 GDR - KB5091158

Описание: KB5091158

Скачать: SQLServer2022-KB5091158-x64.exe

Дата выпуска: 12.05.2026

SQL Server 2022 — Версия: 16.0.1180.1

Исправление безопасности для SQL Server 2019 CU32 - KB5090407

Описание: KB5090407

Скачать: SQLServer2019-KB5090407-x64.exe

Дата выпуска: 12.05.2026

SQL Server 2019 — версия: 15.0.4470.1

Исправление безопасности для SQL Server 2019 GDR - KB5090408

Описание: KB5090408

Скачать: SQLServer2019-KB5090408-x64.exe

Дата выпуска: 12.05.2026

SQL Server 2019 — версия: 15.0.2170.1