Еще одно преимущество данного метода состоит в том, что оптимизатору можно указать, какие индексы использовать при налигии выбора и что оптимизировать - пропускную способность (ALL ROWS) или время реакции (FIRST ROWS).

Хочется верить, что когда оптимизатор по стоимости версии 7.3 окончательно созреет , отключение индексов станет забытым искусством.

Составные индексы

Как упоминалось выше, индексы, состоящие более чем из одного столбца, называются составными. Они встречаются очень часто и являются прямым следствием существования составного первичного ключа таблицы, особенно если таблица соответствует промежуточной сущности. Пример такой таблицы (EMPLOYEESKILLS) приведен на рис. 6.5.

Employee Skills

Skill

Employec

Employee Skills

Puc. 6.5. Таблица с составным индексом

Поскольку в этом примере мы обрабатываем данные о работниках разных компаний, то таблица EMPLOYEE SKILLS имеет индекс для трех столбцов внешнего ключа (F EMP CO#, F EMP EMP#, F SKILL). Важно, чтобы столбцы в этом индексе располагались в оптимальном порядке. Необходимо также рассмотреть возможность дополнения этого индекса еще одним. Многие годы в документации Oracle утверждалось, что столбцы в индексе должны располагаться по порядку их избирательности. Это совершенно бессмысленный совет, полностью игнорирующий цели, для которых создается и применяется индекс! Помните, мы говорили, что Oracle будет использовать индекс только в том случае, если в запросе указана лидирующая часть ключа. В нашем примере с таблицей EMPLOYEE SKILLS Oracle будет использовать индекс для поиска конкретного работника в конкретной

(сомпании, а не для поиска конкретной специальности (если только не указам Я конкретный работник). Ниже приведены примеры SQL-запросов, в которых применяется часть индекса, весь индекс и вообще не используется индекс:

SELECT ems.* /* используются первые две части ключа */ FROM employee skills ems WHERE ems.f emp co# = 23 AND ems.f emp emp# = 1234;

SELECT ems.* /* используется весь индекс */ FROM employee skills ems WHERE ems.f emp co# =23

AND ems.f emp emp# =1234;

AND em3.f skill = WRITING;

SELECT ems.* /* индекс не используется */ FROM employee skill3 ems WHERE em3.f skill = WRITING;

SELECT ems.* /* используется лидирующая часть индекса для поиска компании, а затем производится прямое сканирование индекса - поиск WRITING производиться не будет, WRITING будет найдено в индексе при сканировании */ FROM employee skills ems WHERE ems . f emp co# = 23

AND ems.f skill = WRITING;

Если мы хотим произвести поиск в EMPLOYEE SKILLS только по специальности или соединить эту таблицу с таблицей SKILLS, не соединяя ее с таблицей EMPLOYEES, то лучше создать неуникальный индекс для столбца F SKILL. Можно создать уникальный индекс для столбцов (F SKILL, F EMP CO#, F EMP EMP#), но мы не рекомендуем так делать. Это повлечет за собой лишние затраты при вставке новой строки, поскольку Oracle придется проверять два индекса на предмет наличия значения-дубликата. Если в вашем приложении (или в приложении, требующем оптимальной производительности) часто используется последняя из приведенных выше форм запроса, то рекомендуем создать неуникальный индекс для столбцов (F SKILL, F EMP CO#).

В данном примере нам вряд ли когда-нибудь потребуется осуществлять поиск по столбцу F EMP EMP#, но бывают случаи, где такая средняя часть ключа полезна сама по себе. Руководящий принцип здесь - стремиться к так Называемой треугольной модели * индексных ключей, включающей наиболее часто используемые (или самые критичные для производительности) индексные клюги. Треугольная модель для нашего примера будет выглядеть так:

Этот подход к индексированию официально предложен Крисом Эллисом, бывшим сотрудником Oracle Софога(1оп UK Ltd., а термин треугольная модель изобретен Дейвом Энсором для описания визуального эффекта, получаемого при записи этих ключей один над другим. Если вам кажется, что на треугольник это не похоже, можете выдумать свой собственный термин.

(f emp co#, f emp emp#, f skill) (f skill, f emp co#)

(f emp emp#) , ,

Принимая решение об индексировании, соблюдайте следующие общие правила.

Должно быть в наличии ограничение PRIMARY KEY (которое, конечно, сгенерирует уникальный индекс).

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

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

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

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

Выбор оптимизатора

Среди новых особенностей Oracle?, анонсированных с большой помпой, было появление оптимизатора по стоимости (или статистического оптимизатора) в качестве альтернативы старому оптимизатору по правилам. (Оптимизатор по правилам можно использовать, но Oracle планирует в конечном итоге отказаться от него.) Выбор оптимизатора существенно влияет на применение индексов и в значительной степени является проектным решением. Несмотря на громкую рекламу оптимизатора по стоимости, внедрение его в эксплуатацию осуществляется довольно медленно, вследствие болезней роста и недостатков функциональности. Oracle версии 7.3 - это, вероятно, первый выпуск, где мы действительно советуем использовать этот оптимизатор.

nptt.MeictHtie

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