Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 48

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 42 43 44 45 46 47 < 48 > 49 50 51 52 53 54 .. 161 >> Следующая


Универсальные техники управления планами

В этом разделе описано несколько независимых от используемого сервера баз данных техник управления планами выполнения. Эти методы удобно использовать для следующих целей.

¦ Использовать правильный индекс.

¦ Запретить использование неподходящих индексов.

¦ Использовать желаемый порядок соединения.

¦ Запретить соединения в неправильном порядке;

¦ Выбрать порядок выполнения внешних запросов и подзапросов.

¦ Предоставить оптимизатору верные данные для анализа.

¦ Нагрузить стоимостный оптимизатор плохими данными.

Эти способы часто являются хорошей альтернативой специальным методам для достижения желаемых планов выполнения. Если у вас есть выбор, какую технику
Универсальные техники управления планами

97

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

Использование правильного индекса

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

НекоторыйПсевдоник.Ведуций_индексированный_столбец - <Выражение>

В менее удачном случае сравнение выполняется с некоторым диапазоном значений при помощи операторов BETWEEN, LIKE, <, >, <= или >-. Сравнения по диапазону значений потенциально позволяют использовать индекс, но диапазон индекса, вероятнее всего, будет больше, и результирующий запрос будет работать медленнее. Если диапазон индексированных значений слишком большой, оптимизатор может сделать вывод, что индекс использовать не стоит, и выберет другой путь доступа к данным. Если вы комбинируете условия равенства и поиска в диапазоне для многостолбцовых индексов, следует предпочесть индексы, ведущими в которых являются столбцы, для которых указаны условия равенства. Столбцы, на которые наложены условия диапазона значений, должны находиться в конце индекса. Обратите внимание, что в левой части сравнения просто указано имя столбца, без применения к нему функции и безо всяких выражений (например, сложения) с использованием этого столбца. Использование функции, преобразования типов или арифметического выражения для индексированного столбца в общем случае приведет к невозможности использования индекса.

Преобразования типов — это особенно тонкий момент. Из-за них SQL-сервер иногда отказывается от использования индекса. DB2 возвращает ошибку при попытке сравнить два выражения несовместимых типов. SQL Server предпочитает выполнить неявное преобразование той стороны сравнения, которая не приведет к невозможности использования индекса. Oracle неявно преобразует выражения символьного типа в тот тип данных, который используется запросом, даже если это повлечет за собой отключение индекса. Например, рассмотрим такое выражение:

P.Phone_Number=5551212

Если Phone_Number — столбец символьного типа, то на внутреннем уровне в Oracle и SQL Server это выражение будет преобразовано по-разному.

В Oracle мы получим выражение T0_NUMBER(P. Phone_Number)=5551212

В SQLServer: P.Phone_Nurnber=CAST(5551212 AS VARCHAR)

SQL Server сохраняет индексированный доступ к столбцу в результате произведенного преобразования. В Oracle неявное применение операции T0_NUMBER() сделает невозможным использование индекса точно так же, как если бы вы указали это выражение явно. На самом деле разница лишь в том, что неявную форму приведения типов обнаружить сложнее. Ta же проблема может помешать использовать индексы для соединений и для однотабличных условий. Например, возьмем соединение:

P.Phone Number-C.Contact Number
98

4. Управление планами выполнения

Если Contact_Number принадлежит числовому типу, a Phone_Number — символьному, то неявное преобразование в Oracle запрещает использовать вложенные циклы по индексу для соединения С с Р. Соединение в обратном порядке пройдет беспрепятственно. Выражение напротив упоминания индексированного столбца может быть сколь угодно сложным. Ho в нем не должны упоминаться столбцы с тем же псевдонимом, который указан для индексированного столбца. Например:

P.Phone_Number=P.Area_Code||'5551212'

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

Есть еще один случай, когда SQL зачастую запрещает использовать индекс — когда условия соединены оператором OR. Рассмотрим, например такой запрос: SELECT ...

FROM OrderJtetails D.

WHERE ...

AND (D.Order_ID=:l or :1 IS NULL)
Предыдущая << 1 .. 42 43 44 45 46 47 < 48 > 49 50 51 52 53 54 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100