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

Давайте начнем с создания таблицы и заполнения ее 3 тысячами записей для использования в наших примерах. Выполните следующий скрипт T-SQL:

CREATE TABLE ExPlanOperator_P2 (
    ID INT IDENTITY (1, 1),
    EmpFirst_Name VARCHAR(50),
    EmpLast_name VARCHAR(50),
    EmpAddress VARCHAR(MAX),
    EmpPhoneNum VARCHAR(50)
)

INSERT INTO ExPlanOperator_P2 VALUES ('AB', 'BA', 'CB', '123123')
GO 1000
INSERT INTO ExPlanOperator_P2 VALUES ('DA', 'EB', 'FC', '456456')
GO 1000
INSERT INTO ExPlanOperator_P2 VALUES ('DC', 'EA', 'FB', '789789')
GO 1000

Теперь давайте перейдем к первому оператору, который мы обсудим в этой статье: оператору поиска по RID в SQL Server.

Оператор поиска по RID в SQL Server

Предположим, что у нас есть Не кластеризованный индекс на столбце EmpFirst_Name таблицы ExPlanOperator_P2. Выполните следующий оператор T-SQL для создания индекса:

CREATE INDEX IX_ExPlanOperator_P2_EmpFirst_Name ON ExPlanOperator_P2 (EmpFirst_Name)

Если вы выполните следующий оператор SELECT для получения информации о всех сотрудниках с определенным значением EmpFirst_Name:

SELECT * FROM ExPlanOperator_P2 WHERE EmpFirst_Name = 'BB'

При проверке плана выполнения SQL Server, сгенерированного после выполнения запроса, вы увидите, что Оптимизатор запросов SQL Server использует Не кластеризованный индекс для поиска всех сотрудников с значением EmpFirst_Name, равным ‘BB’, без необходимости сканировать всю таблицу. Однако Не кластеризованный индекс не содержит все запрошенные столбцы. Он содержит только значения ключевых столбцов и указатель на остальные столбцы в базовой таблице.

Для получения остальных столбцов SQL Server Engine использует оператор вложенных циклов для объединения данных поиска по индексу с набором данных, полученных из оператора поиска по RID. Оператор поиска по RID, также известный как оператор идентификатора строки, использует указатели из Не кластеризованного индекса для нахождения и извлечения остальных столбцов из базовой таблицы.

Важно отметить, что оператор поиска по RID может быть затратным, особенно при работе с большим количеством записей. Для оптимизации запроса можно рассмотреть его переписывание для ограничения извлекаемых столбцов или создание покрывающего индекса.

Оператор поиска по ключу в SQL Server

Оператор поиска по ключу является кластерным эквивалентом оператора поиска по RID. Предположим, что у нас есть Кластеризованный индекс на столбце ID таблицы ExPlanOperator_P2. Выполните следующий оператор T-SQL для создания индекса:

CREATE CLUSTERED INDEX IX_ExPlanOperator_P2_ID ON ExPlanOperator_P2 (ID)

Если вы выполните тот же самый оператор SELECT, что и раньше:

SELECT * FROM ExPlanOperator_P2 WHERE EmpFirst_Name = 'BB'

При проверке плана выполнения SQL Server вы заметите, что SQL Server Engine выполняет операцию поиска по Не кластеризованному индексу для извлечения всех сотрудников со значениями столбца EmpFirst_Name, равными ‘BB’. Однако не все столбцы могут быть извлечены из Не кластеризованного индекса. SQL Server Engine использует указатели из Не кластеризованного индекса для нахождения остальных столбцов в базовой таблице.

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

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

Оператор сортировки в SQL Server

Предположим, что мы выполняем следующий оператор SELECT для получения списка сотрудников с определенным значением EmpFirst_Name из таблицы ExPlanOperator_P2, отсортированным по значениям столбца EmpLast_Name в порядке убывания:

SELECT * FROM ExPlanOperator_P2 WHERE EmpFirst_Name = 'BB' ORDER BY EmpLast_Name DESC

При проверке плана выполнения SQL Server вы увидите, что SQL Server Engine выполняет поиск по Не кластеризованному индексу для извлечения запрошенных данных. Результат оператора поиска по индексу передается оператору SORT для сортировки данных в соответствии с указанным в операторе ORDER BY порядком.

Оператор сортировки может быть затратным, особенно если на столбце, указанном в операторе ORDER BY, не определен индекс. Для оптимизации запроса можно рассмотреть, действительно ли необходима операция сортировки. Если ее можно избежать, лучше не использовать ее или создать индекс, чтобы иметь отсортированную копию столбца и избежать накладных расходов оператора SORT.

Это завершает наше обсуждение второго набора операторов плана выполнения SQL Server. Следите за следующей статьей, где мы р