Индексы на базе В*-деревьев


Оптимизация по синтаксису



бет9/10
Дата01.11.2022
өлшемі239.92 Kb.
#463783
1   2   3   4   5   6   7   8   9   10
Все лекции (1) (1) (1)

Оптимизация по синтаксису


Оптимизатор запросов был в Oracle всегда, но до версии Oracle7 существовал только оптимизатор по синтаксису. В нем для принятия решения применяется набор предопределенных правил. Поскольку начиная с версии Oracle Database 10g* оптимизатор по синтаксису не поддерживается, эта тема может интересовать вас только в связи с необхо- димостью поддерживать старые базы данных, где еще имеется выбор.
В некоторых ситуациях оптимизация по синтаксису обеспечивает лучшую производительность, чем ранние версии оптимизатора Oracle по стоимости. Но у оптимизатора по синтаксису есть слабые стороны, одна из которых - чересчур упрощенный набор правил. В Oracle есть около 20 правил, каждому из которых приписан определенный вес. В сложных базах данных запросы часто строятся по нескольким таблицам, имеющим по нескольку индексов, с применением сложных условий и сортировок. Результатом такой сложности становится обилие путей выполнения, и слишком простой набор правил не позволяет сделать наилучший выбор.
Оптимизатор по синтаксису назначает каждому потенциальному пути выполнения некоторую оценку, а затем выбирает путь с наилучшей оценкой. Другая слабость оптимизатора по синтаксису проявляется в ситуации, когда имеются пути с одинаковыми оценками. В этом случае оптимизатор разрешает конфликт с помощью синтаксиса SQL-запроса. Выбор окончательного пути определяется тем, в каком порядке таблицы упоминаются в SQL-команде.
К каким последствиям приводит такой алгоритм разрешения конфликтов, можно понять, рассмотрев простой случай, когда маленькая таблица SMALLTAB из 10 строк соединяется с большой таблицей LARGETAB из 10 000 строк (рис. 4.4). Если бы оптимизатор решил сначала читать SMALLTAB, то серверу пришлось бы считать 10 строк, а потом найти в LARGETAB соответствующие им строки. Но если оптимизатор сочтет, что сначала следует читать LARGETAB, то сервер прочтет 10 000 строк, а потом будет 10 000 раз просматривать SMALLTAB в поисках соответствий. Конечно, строки из SMALLTAB, скорее всего, окажутся в кэше, что сократит затраты на каждый просмотр, но разница в производительности тем не менее будет огромной.
Такие казусы зависят от порядка упоминания таблиц в запросе. В описанной ситуации будут возвращены одни и те же результаты при обоих путях выполнения, но ресурсы, затраченные на их получение, различаются весьма существенно.


Достарыңызбен бөлісу:
1   2   3   4   5   6   7   8   9   10




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет