Что на самом деле означает слово «SARGable»?

Пользователи SQL Server используют термин «sargable» . Мне интересно, существует ли объективное, независимое от реализации определение вне времени для "sargable".

Например, WHERE foo LIKE '%bar%'многие говорят, что это не sargable , но некоторые РСУБД могут использовать индексы для таких запросов . Что же значит «не саргализируемый» ?

Другие ссылки

• Что делает оператор SQL саргным?

Термин «sargable» был впервые введен P. Griffiths Selinger et al. в своей статье 1979 года «Выбор пути доступа в системе управления реляционными базами данных», опубликованной ACM . Для тех, кто не является членом ACM, есть копия этого документа по адресу http://cs.stanford.edu/people/chrismre/cs345/rl/selinger.pdf.

Термин определен в этом параграфе:

При сканировании как по индексу, так и по сегменту ¹ может необязательно приниматься набор предикатов, называемых поисковыми аргументами (или SARGS), которые применяются к кортежу перед его возвратом вызывающей стороне RSI ² . Если кортеж удовлетворяет предикатам, он возвращается; в противном случае сканирование продолжается до тех пор, пока не будет найден кортеж, который удовлетворяет SARGS, или не исчерпан сегмент или указанный диапазон значений индекса. Это снижает стоимость за счет устранения накладных расходов на выполнение вызовов RSI для кортежей, которые могут быть эффективно отклонены в RSS. Не все предикаты имеют форму, которая может стать SARGS. Sargable предикат является одним из формы (или который может быть введен в форму) «столбец оператор сравнения значения». SARGS выражаются как логическое выражение таких предикатов в дизъюнктивной нормальной форме.

Другими словами, предикат sargable является таким, который может быть разрешен механизмом хранения (методом доступа) путем непосредственного наблюдения за таблицей или индексной записью. И наоборот, предикат без аргументов требует более высокого уровня работы СУБД. Например, результат WHERE lastname = 'Doe'может быть определен механизмом хранения, просто просматривая содержимое поля lastnameкаждой записи. С другой стороны, WHERE UPPER(lastname) = 'DOE'требует выполнения функции механизмом SQL, что означает, что механизм хранения должен будет вернуть все строки, которые он читает (при условии, что они соответствуют возможным другим, sargable предикатам), обратно в механизм SQL для оценки, что приведет к дополнительным затратам ЦП. ,

Из исходного определения видно, что sargable предикаты могут применяться не только к просмотрам индекса, но и к просмотрам таблиц (сегментов в терминологии System R), если выполняются условия «значение оператора сравнения столбцов», и поэтому они могут быть оценивается механизмом хранения. Это действительно так с Db2, потомком System R во многих отношениях :

Предикаты sargable индекса не используются для ограничения поиска, но оцениваются по индексу, если он выбран, поскольку столбцы, включенные в предикат, являются частью ключа индекса. Эти предикаты также оцениваются менеджером индекса.

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

Тот факт, что в SQL Server-говорящих предикатах sargable есть только те, которые могут быть разрешены с помощью поиска индекса, вероятно, определяется неспособностью механизма хранения применять такие предикаты во время сканирования таблиц.

Предикаты Sargable и Non-Sargable иногда описываются как предикаты «стадии 1» и «стадии 2» соответственно (это также происходит из терминологии Db2 ). Предикаты этапа 1 могут оцениваться на самом низком уровне обработки запросов при чтении записей таблицы или индекса. Строки, соответствующие условиям этапа 1, если таковые имеются, отправляются на следующий уровень, этап 2 оценки.

¹ - Сегмент в System R - это физическое хранилище кортежей таблицы; сканирование сегментов в некоторой степени эквивалентно сканированию таблиц в других СУБД.

² - Интерфейс RSI - RSS ^3, интерфейс запросов, ориентированный на кортежи. Интерфейсной функцией, относящейся к этому обсуждению, является NEXT, которая возвращает предикаты запроса на соответствие следующей строки.

³ - RSS, или Research Storage System, подсистема хранения System R.

Для меня SARGable означает, что SQL Server может выполнять поиск по индексу, используя ваши предикаты поиска.

Нельзя просто сказать, что СУБД может «воспользоваться» индексом, потому что с предикатом без аргументов SQL Server может в конечном итоге сканировать некластеризованный индекс.

По словам Pro SQL Server Internals Дмитрия Короткевича :

Предикат поиска ARGment ABLE - это предикат, в котором SQL SERVER может использовать операцию поиска по индексу, если индекс существует.

Предикат SARGable - это предикат, в котором сервер SQL может изолировать одно значение или диапазон значений ключа индекса для обработки.

SARGable предикат включает в себя следующие операторы: =, >, >=, <, <=, IN, BETWEEN, и LIKE( в случае совпадения префикса )

Номера SARGable операторы включают в себя: NOT, NOT IN, <>, и LIKE( не совпадающим префиксом ), а также использование функций или расчетов по таблице, и преобразования типов , где тип данных не соответствует индексу созданного.

Пример :

WHERE name like 'SARGable%'
WHERE name like '%non-SARGable%'

Демо :

DROP TABLE dbo.Testing;
GO

CREATE TABLE Testing (
    WeirdDatatype   int NOT NULL,
    SomethingElse   char(200)
);

CREATE NONCLUSTERED INDEX IDX_ALWAYS_SARGable
    ON dbo.Testing( SomethingElse);

CREATE NONCLUSTERED INDEX IDX_NOT_ALWAYS_SARGable
    ON dbo.Testing(SomethingElse);

INSERT INTO dbo.Testing
        ( WeirdDatatype, SomethingElse )
SELECT TOP 1000 m.message_id, CONVERT(char(200), m.text)
FROM sys.messages AS m;

Теперь мы бежим:

SELECT *
FROM dbo.Testing AS t
WHERE  t.WeirdDatatype = 1001;
SELECT *
FROM dbo.Testing AS t
WHERE t.SomethingElse LIKE 'Line%'
SELECT *
FROM dbo.Testing AS t
WHERE t.SomethingElse LIKE '%Line%'
     AND t.WeirdDatatype = 1001;

Результаты:

Давайте посмотрим на свойства запроса SARGable (поиск по индексу)

Оптимизатор запросов может определить ограничение в индексе начала и конца. У него есть аргумент поиска для запроса.

Теперь запрос без SARGable:

Вы можете видеть, что начало предиката «% non ..%» не позволяет оптимизатору запросов определять начало и конец или диапазон в индексе. Теперь он должен искать всю таблицу (сканирование).