Microsoft SQL Server *

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

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

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам статьи Craig Freedman: Parallel Hash Join

SQL Server использует один из двух вариантов стратегии распараллеливания хэш-соединения. Наиболее часто встречается хэш-секционирование (Hash Partitioning). Реже можно встретить Broadcast-секционирование; эту стратегию часто называют "Broadcast hash join".

Хэш-секционирование

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

Перевод Ирины Наумовой.

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам статьи Craig Freedman: Parallel Nested Loops Join

SQL Server распараллеливает Nested Loops Join, распределяя в случайном порядке строки внешней таблицы по потокам вложенных циклов. В данном случае, речь идёт о строках, которые поступают первыми, и мы их видим вверху, на графическом плане запроса. Например, если на входе соединения вложенных циклов имеется два потока, каждый поток получит приблизительно половину строк. Потоки проходятся по строкам внутренней таблицы соединения (то есть, по строкам, поданным во вторую очередь, мы их видим ниже в плане запроса), точно по такому же алгоритму, как это было бы реализовано в сценарии с последовательной обработкой строк. Таким образом, для каждой обрабатываемой потоком строки внешней таблицы, поток обеспечивает соединение своей внутренней таблицы, используя эту строку в качестве источника коррелированных параметров. Это позволяет потокам работать независимо друг от друга. При этом для внутренней таблицы соединения вложенных циклов SQL Server не добавляет операторы параллелизма и работу с ней не распараллеливает.

Перевод Ирины Наумовой

По материалам статьи Craig Freedman: Parallel Scan

В этой статье я собираюсь рассмотреть то, как SQL Server распараллеливает просмотр таблицы (сканирования - scans). Оператор просмотра - один из немногих операторов, которые адаптированы к параллелизму. Большинство других операторов ничего не знают о параллелизме, и не заботятся о том, выполняются ли они параллельно; оператор просмотра является в этом случае исключением.

Перевод Ирины Наумовой.

По материалам статьи Craig Freedman: The Parallelism Operator (aka Exchange)

Как я уже писал в статье Введение в распараллеливание исполнения запроса , итератор параллелизма (или обмена - Exchange operator) фактически привносит в процесс выполнения запроса возможность распараллеливания задачи. Оптимизатор помещает оператор обмена в том месте, где происходит разделение на несколько потоков, и оператор обмена перемещает строки между потоками.

Перевод Ирины Наумовой.

По материалам статьи Craig Freedman: Index Union
Перевод Ирины Наумовой

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

У меня в планах на этот год на Хабре было опубликовать пару статей по колумсторам и XML. Материала за годы накопилось предостаточно и выходило на 30..40 страниц текста - фактически мини-книга. Но когда за окном Градами и прочей дичью херячили месяц... оно как-то не складывалось настроиться на конструктив. Вначале агрессия на виновников этой дичи, потом паника за близких... печаль что все планы порушились и непонятно что ждать. А сейчас прям совсем ровно на все жизненные трудности ибо как-то получается разруливать все и помогать людям.

Так вот... со знакомым решили вернуться к прежней теме и постримить сегодня о колумсторах. Без политики, срача и прочего. Очень много шутеек о том как живеться в условиях спецоперации и немного полезной инфы о колумсторах на SQL Server.

Кто хочет из коллег послушать: https://www.youtube.com/watch?v=wXH3fUN0PsM

You are welcome!

По материалам статьи Craig Freedman: Introduction to Parallel Query Execution

SQL Server умеет выполнять запросы одновременно на нескольких процессорах. Такую возможность принято называть параллельным исполнением запроса. Параллельное исполнение запроса может использоваться для сокращения времени отклика (то есть, повышение быстродействия) больших запросов. Оно также может использоваться и при исполнении больших запросов (которые обрабатывают большой объём данных) в одно и то же время с маленькими запросами (масштабирование), увеличивая число процессоров, используемых в обслуживании запроса. Для большинства больших запросов SQL Server масштабируется практически линейно или почти линейно. Повышение быстродействия тут означает, что если мы удваиваем число процессоров, мы можем наблюдать сокращение времени отклика тоже в два раза. Масштабирование тут означает, что если мы удваиваем число процессоров и размер запроса, мы получает то же самое время отклика.

По материалам статьи Craig Freedman: Hash Aggregate

В двух своих предыдущих статьях, я писал об операторе агрегации потока. Агрегат потока хорошо подходит для скалярных агрегатов и для агрегации с использованием индекса, который обеспечивает порядок сортировки по столбцу(цам) предложения GROUP BY или когда сортировка задана явно (например, указано предложение ORDER BY).
Следующий оператор агрегации, это агрегат хэша, который подобен хэш-соединению. Он не требует указания порядка сортировки, зато потребляет память и устанавливает блокировку (то есть, он не выдаёт результатов, пока не обработает всё, что у него на входе). Агрегат хэша является лучшим выбором для эффективной агрегации очень больших наборов данных.
Вот так выглядит алгоритма агрегата хэша в псевдокоде:

По материалам статьи Craig Freedman: Stream Aggregate

Когда мы имеем дело с предложением GROUP BY, SQL Server для вычисления агрегатов использует два оператора. Один из этих операторов - агрегат потока, который, как Вы помните, был рассмотрен в предыдущей статье, и который используется для скалярных агрегатов. Другой оператор, это агрегат хэша (Hash Aggregate). В этой статье, я более подробно рассмотрю то, как работает агрегат потока.

По материалам статьи Craig Freedman: Aggregation

Агрегация относится к таким операциям, когда больший набор строк свёртывается в меньший. Типичные агрегатные функции - COUNT, MIN, MAX, SUM и AVG. SQL Server поддерживает также и другие агрегаты, типа STDEV и VAR.

Я собираюсь посвятить этой теме несколько статей. В этой статье, я сосредоточусь на "Скалярных Агрегатах". Скалярные агрегаты - запросы с агрегатными функциями в списке оператора SELECT и без предложения GROUP BY. Скалярные агрегаты всегда возвращают одну строку.

По материалам статьи Craig Freedman: Subqueries: ANDs and ORs

В статье Введение в соединения, я показал примеры того, как можно использовать полусоединение для оценки подзапроса в EXISTS. В качестве резюме, давайте рассмотрим другой пример:

По материалам статьи Craig Freedman: Subqueries in CASE Expressions

В этой статье будет рассмотрено, как SQL Server обрабатывает подзапросы в выражении CASE. Кроме того, будут рассмотрены несколько экзотических возможностей соединений.

По материалам статьи Craig Freedman: Summary of Join Properties

Следующая таблица суммирует характеристики трех операторов соединения, которые были описаны в моих трех предшествующих статьях.

Когда Вы встречаете случай использования оператора Hash Join (хэш-соединение), это говорит о наличии тяжелого запроса. В отличие то соединения Nested Loops Join, которое хорошо для относительно маленьких наборов данных, и от соединения Merge Join, которое помогает при умеренных размерах наборов данных, хэш-соединение превосходит другие типы соединений при необходимости соединения огромных наборов данных. Хэш-соединения распараллеливается и масштабируется лучше любого другого соединения и сильно выигрывает при большой производительности информационных хранилищ (я вернусь к обсуждению параллельного выполнения запросов в следующей серии статей).

Хэш-соединение имеет много общего с соединением слиянием. Подобно соединению слиянием, для него требуются не менее одного предиката объединения по эквивалентности, оно поддерживает остаточные предикаты, а также все внешние соединения и полусоединения. В отличие от соединения слиянием, для него не требуется наличие упорядоченных входных потоков и для поддержки полного внешнего соединения требуется наличие предиката соединения по эквивалентности.

По материалам статьи Craig Freedman: Merge Join

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

Этот алгоритм в псевдокоде можно выразить следующим образом:

Эта статья посвящена физическому оператору соединения - соединению слиянием (Merge Join или MJ). В отличие от Nested Loops Join, которое поддерживает любые предикаты соединения, соединение слиянием требует существования не менее одного предиката соединения по эквивалентности. Кроме того, получаемые соединением слиянием данные должны быть отсортированы по ключу соединения. Например, если мы имеем предикат соединения "T1.a = T2.b", таблица T1 должна быть отсортирована по T1.a, а таблица T2 должна быть сортирована по T2.b.

По материалам статьи Craig Freedman: Nested Loops Join

SQL Server поддерживает три физические оператора соединений: соединение вложенных циклов, соединение слиянием и хэш-соединение. В этой статье я опишу соединение вложенных циклов - Nested Loops Join (или NL-соединение, для краткости).

По материалам статьи Craig Freedman: Introduction to Joins

Можно соединить две таблицы явно, перечислив обе таблицы в предложении FROM запроса. Также можно соединить две таблицы, используя для этого всё разнообразие подзапросов. Наконец, SQL Server во время оптимизации может добавить соединение в план запроса, преследуя свои цели.

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

Соединение (JOIN) - одна из самых важных операций, выполняемых реляционными системами управления базами данных (РСУБД). РСУБД используют соединения для того, чтобы сопоставить строки одной таблицы строкам другой таблицы. Например, соединения можно использовать для сопоставления продаж - клиентам или книг - авторам. Без соединений, имелись бы раздельные списки продаж и клиентов или книг и авторов, но невозможно было бы определить, какие клиенты что купили, или какой из авторов был заказан.

По материалам статьи Craig Freedman

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

Перед тем, как SQL Server приступит к поиску по индексу, он должен определить, являются ли ключи индекса подходящими для оценки предиката запроса.

С индексами по одному столбцу всё довольно просто. SQL Server может их использовать для самых простых сравнений, например, равенства и неравенства (больше чем, меньше чем, и т.д.). Более сложные выражения, такие как функции по столбцу и предикаты "LIKE" с символами подстановки, будут в таких случаях создавать трудности для использования поиска по индексу.