Саргейбл

В реляционных базах данных условие (или предикат) в запросе считается доступным для анализа, если механизм СУБД может использовать индекс для ускорения выполнения запроса. Этот термин происходит от сокращения Search ARGument ABLE . Впервые оно было использовано исследователями IBM как сокращение от Search ARGument и стало означать просто «можно найти по индексу». ¹^[1]^[2]

Для оптимизаторов запросов к базе данных является sargable важным свойством в рабочих нагрузках OLTP , поскольку предполагает, что хороший план запроса может быть получен с помощью простой эвристики. ² сопоставление запроса с индексами вместо сложного, трудоемкого поиска, основанного на затратах, ^[1] поэтому часто желательно писать запросы с возможностью Саргинга. Запрос, который не может быть Саргабельным, называется запросом без Саргирования и обычно оказывает негативное влияние на время запроса, поэтому одним из шагов оптимизации запросов является преобразование их в Саргабельные. Эффект аналогичен поиску определенного термина в книге, не имеющей указателя, каждый раз начиная с первой страницы, вместо перехода к списку конкретных страниц, указанных в указателе.

Типичная ситуация, при которой SQL-запрос становится невозможным для анализа, — это включение в предложение WHERE функции, работающей со значением столбца. Предложение WHERE — не единственное предложение, в котором возможность выделения может иметь значение; это также может повлиять на предложения ORDER BY, GROUP BY и HAVING. Предложение SELECT, с другой стороны, может содержать выражения, не поддающиеся анализу, без отрицательного влияния на производительность.

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

Саргабельные операторы: =, >, <, >=, <=, BETWEEN, LIKE, IS [NOT] NULL, IN
Саргабельные операторы, которые редко улучшают производительность: <>, NOT, NOT IN, NOT LIKE

Простой пример

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

Не подлежит саргументу:

SELECT *
FROM   myTable
WHERE  SQRT(myIntField) > 11.7

Это невозможно , поскольку myIntField встроен в функцию. Если бы в myIntField были доступны какие-либо индексы, их нельзя было бы использовать. Кроме того, SQRT() будет вызываться для каждой записи в myTable.

Саргабельная версия:

SELECT *
FROM   myTable
WHERE  myIntField > 11.7 * 11.7

Это можно использовать, поскольку myIntField НЕ содержится в функции, что делает потенциально пригодными для использования любые доступные индексы в myIntField. Более того, выражение вычисляется только один раз, а не для каждой записи в таблице.

Пример текста

WHERE ... LIKE предложения, которые доступны для Саргинга, имеют значения полей слева от оператора, и LIKE текстовые строки, которые не начинаются с % справа.

Не подлежит саргументу:

SELECT *
FROM   myTable
WHERE  myNameField LIKE '%Wales%' -- Begins with %, not sargable

Это несерьезно . Он должен проверить каждую строку, чтобы найти поля, содержащие подстроку 'Wales' в любом положении.

Саргабельная версия:

SELECT *
FROM   myTable
WHERE  myNameField LIKE 'Jimmy%' -- Does not begin with %, sargable

Это вполне объяснимо. Он может использовать индекс для поиска всех значений myNameField, которые начинаются с подстроки. 'Jimmy'.

См. также

Примечания

^ 1 Гулуцан и Пельцер ( Глава 2, Простые «поиски» )

^2 ^[3] приводит пример такой простой эвристики.

Внешние ссылки

Ссылки

^ Перейти обратно: ^а ^б Энди, Павел (весна 2023 г.). «CMU 15-721 :: Расширенные системы баз данных (весна 2023 г.) :: Лекция № 16 «Реализация оптимизатора (Часть 1) — слайд» (PDF) . Архивировано (PDF) из оригинала 1 июня 2023 г. Проверено 25 января 2024 г.
^ Селинджер, П. Гриффитс; Астрахань, ММ; Чемберлин, Д.Д.; Лори, РА; Прайс, Т.Г. (1979). «Выбор пути доступа в системе управления реляционными базами данных» . SIGMOD '79: Материалы Международной конференции ACM SIGMOD 1979 года по управлению данными . ACM Press: 23. doi : 10.1145/582095.582099 . ISBN 978-0-89791-001-9 .
^ Зильбершац, Авраам; Корт, Генри Ф.; Сударшан, С. (2020). Концепции системы баз данных (7-е изд.). Нью-Йорк, штат Нью-Йорк: McGraw-Hill Education. п. 773. ИСБН 978-1-260-08450-4 .

Настройка производительности SQL , Питер Гулуцан, Труди Пельцер (Аддисон Уэсли, 2002 г.) ISBN 0-201-79169-2 ( Глава 2, Простые «поиски» )
Внутреннее устройство Microsoft SQL Server 2012, авторы: Кален Делани, Коннор Каннингем, Джонатан Кехайяс, Бенджамин Неварес, Пол С. Рэндал (О'Рейли, 2013 г.) ISBN 978-0-7356-5856-1 (Глава 11, Оптимизатор запросов)

[:0-1] Перейти обратно: ^а ^б Энди, Павел (весна 2023 г.). «CMU 15-721 :: Расширенные системы баз данных (весна 2023 г.) :: Лекция № 16 «Реализация оптимизатора (Часть 1) — слайд» (PDF) . Архивировано (PDF) из оригинала 1 июня 2023 г. Проверено 25 января 2024 г.

[2] Селинджер, П. Гриффитс; Астрахань, ММ; Чемберлин, Д.Д.; Лори, РА; Прайс, Т.Г. (1979). «Выбор пути доступа в системе управления реляционными базами данных» . SIGMOD '79: Материалы Международной конференции ACM SIGMOD 1979 года по управлению данными . ACM Press: 23. doi : 10.1145/582095.582099 . ISBN 978-0-89791-001-9 .

[3] Зильбершац, Авраам; Корт, Генри Ф.; Сударшан, С. (2020). Концепции системы баз данных (7-е изд.). Нью-Йорк, штат Нью-Йорк: McGraw-Hill Education. п. 773. ИСБН 978-1-260-08450-4 .

[1]

[2]

[3]