Логика принятия решения о размещении параллельных запросов в SQL Server

Автор: Bob Dorr - MS Principal SQL Server Escalation Engineer, SQL Server Parallel Query Placement Decision Logic

Недавно у меня состоялся разговор с Jonathan Kehayias из sqlskills.com о размещении рабочих потоков, принадлежащих параллельному запросу. Когда я расспрашивал людей и изучал код, я быстро обнаружил, что предположение всё ещё заключается в том, что используется «наименее загруженный узел» (Least Loaded Node), но это изменилось в SQL Server 2012, и осведомлённость об этом как у наших инженеров поддержки, так и у клиентов оставляет желать лучшего. В этой статье я освещаю различные варианты решений, доступные SQL Server 2012, 2014 и 2016.

Форматирование T-SQL запросов в SSMS 22.7

Автор: Chad Callihan , SQL Formatting in SSMS 22.7

Форматирование кода может быть деликатной темой. Иногда существуют чёткие правила, определяющие правильное и неправильное, а иногда их нет. Пробелы против табуляции, что выбрать?

Как ни удивительно, но в SQL Server Management Studio никогда не было встроенного средства форматирования SQL. Пользователям всегда приходилось пользоваться сторонними инструментами или форматировать вручную. Но с выходом последней версии SSMS 22.7 форматирование SQL наконец стало встроенной функцией.

Давайте рассмотрим несколько примеров и посмотрим, как она работает.

Автоматическая soft-NUMA и ожидания SOS_SCHEDULER_YIELD в SQL Server

Автор: Erik Darling, Automatic Soft-NUMA and SOS_SCHEDULER_YIELD Waits In SQL Server

Автоматическая soft-NUMA (auto soft-NUMA) может приводить к увеличению ожиданий SOS_SCHEDULER_YIELD в больших системах с ограниченной конкурентностью больших параллельных запросов. В этой статье содержится воспроизведение проблемы и краткий анализ. Я надеюсь, что читатели из Microsoft оценят мою сдержанность в том, что я не сострил на тему «Это просто работает медленнее».

Шаблонные реакции на статистику ожиданий: SOS_SCHEDULER_YIELD

Автор: Paul Randal, Knee-Jerk Wait Statistics : SOS_SCHEDULER_YIELD

В этой статье я продолжу тему статистики ожиданий и расскажу об ожидании SOS_SCHEDULER_YIELD.

Когда SOS_SCHEDULER_YIELD является преобладающим на сервере, часто наблюдается устойчивое высокое использование ЦП. Шаблонная реакция здесь заключается в том, что сервер, должно быть, испытывает давление на ЦП или что проблема в спинблокировке.

Выявление запросов с ожиданиями SOS_SCHEDULER_YIELD

Автор: Paul Randal, Identifying queries with SOS_SCHEDULER_YIELD waits

Одна из проблем с типом ожидания SOS_SCHEDULER_YIELD заключается в том, что это на самом деле не тип ожидания. Когда возникает этот тип ожидания, это происходит потому, что поток исчерпал свой 4-миллисекундный квант планирования и добровольно уступил ЦП, перейдя непосредственно в конец очереди выполнения (Runnable Queue) для планировщика, минуя список ожидания (Waiter List). Однако ожидание должно быть зарегистрировано, когда поток покидает процессор, поэтому используется SOS_SCHEDULER_YIELD.

Советы и хитрости для высокой производительности FILESTREAM

Автор: Paul Randal, High-performance FILESTREAM tips and tricks

У меня было много вопросов о производительности FILESTREAM и о том, как заставить NTFS хорошо масштабироваться. Я только что закончил писать 30-страничный технический документ о FILESTREAM для команды SQL Server, который должен быть опубликован до конференции PASS 2008 в ноябре. Хотя мой технический документ не совсем о производительности, в нём есть длинный раздел о настройке системы для достижения высокой производительности FILESTREAM. В этой статье я хочу дать список рекомендаций, которые помогут вам добиться хорошей производительности. Все они более подробно описаны в техническом документе.

Могут ли ключи кластерного индекса с типом GUID вызывать фрагментацию некластерных индексов?

Автор: Paul Randal, Can GUID cluster keys cause non-clustered index fragmentation?

На встрече пользовательской группы я потратил некоторое время на объяснение того, как GUID могут вызывать фрагментацию как в кластерных, так и в некластерных индексах, даже если GUID специально не включён в ключ некластерного индекса. GUID — это, по сути, случайные значения (псевдослучайные в диапазонах, если генерируются с помощью NEWSEQUENTIALID), которые также уникальны. Их уникальность делает их привлекательными для многих разработчиков в качестве значения ключа, не понимая при этом того хаоса, который они могут вызвать в производственной среде с точки зрения фрагментации и низкой производительности запросов.

Насколько сложно выбрать правильные некластерные индексы?

Автор: Paul Randal, How hard is it to pick the right non-clustered indexes?

На собрании группы разработчиков .NET в Редмонде, и во время того, как Кимберли рассказывала о пропущенных и лишних индексах, возник следующий вопрос:

«Какой некластерный индекс лучше всего использовать для запроса с условием WHERE lastname = 'Randal' AND firstname = 'Paul' AND middleinitial = 'S'?»

Кимберли сказала, что для этого случая порядок ключей не имеет значения. Я подумал секунду, а затем возразил, сказав, что наиболее селективный столбец должен быть первым. Мы согласились обсудить это с группой в конце, но я подумал ещё немного и понял (и признался группе), что она права – мне следовало бы знать, что не стоит подвергать сомнению знания Кимберли об индексировании… :-)

Разочарование от обобщений

Автор: Paul Randal, The frustration of sweeping generalizations – follow on from Search Engine Q&A #12

Постоянное участие в дискуссиях побудило меня высказать свои мысли о многочисленных обобщениях, которые преследуют индустрию и иногда затрудняют дачу советов на форумах и в блогах. 

Некоторые примеры вопросов, которые порождают обобщения:

• Следует ли создавать кластерные индексы для всех таблиц? (Известный спор о кластерных индексах, как его любит называть Кимберли.)
• Следует ли перестраивать или реорганизовать индексы для устранения фрагментации?
• Какое решение высокой доступности следует использовать?

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

Накопительный пакет обновления SQL Server 2025 CU6 - KB5093421

Описание: KB5093421

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

Дата выпуска: 17 июня 2026 г.

SQL Server 2025 — Версия: 17.0.4055.5

Журнал транзакций SQL Server. Часть 4: записи журнала

Автор: Paul Randal, The SQL Server Transaction Log, Part 4: Log Records

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

Следует ли создавать несколько файлов для пользовательской базы данных на многопроцессорном сервере?

Автор: Paul Randal, Search Engine Q&A #12: Should you create multiple files for a user DB on a multi-core box?

На сайте SQLServerCentral.com развернулась очень интересная дискуссия о том, стоит ли создавать несколько файлов для пользовательской базы данных, потому что на сервере несколько ЦП. Я написал пару длинных ответов в ходе дискуссии и хотел продублировать их здесь, так как считаю, что это представляет широкий интерес.