Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 74

Соединения

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

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

Величина времени, затрачиваемая на поиск во всей таблице, прямо пропорциональна количеству строк в таблице. Индекс для столбца может означать разницу между немедленным ответом на запрос и долгим ожиданием. Так почему бы не индексировать каждый столбец?

Основные препятствия этому состоят в том, что индексы занимают дополнительное дисковое пространство, а добавление, удаление и изменение строк занимает больше времени для индексированных столбцов, чем для не индексированных. Индекс должен быть изменен каждый раз, когда изменяется элемент данных в индексированном столбце, и каждый раз, когда строка добавляется в таблицу или удаляется из таблицы.

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

* условие поиска часто ссылается на столбец (Индекс поможет в поиске дат и чисел, когда ожидается прямое сравнение или вычисление BETWEEN. Поисковые индексы для строковых столбцов полезны, когда строки проверяются на точное соответствие или в предикатах STARTING WITH и CONTAINING. Они не годятся для предиката LIKE[52].);

* столбец не включен в ограничение целостности, но на него часто ссылается условие в JOIN;

* предложение ORDER BY часто использует столбец для сортировки данных (Когда набор данных должен быть упорядочен по нескольким столбцам, составной индекс, соответствующий порядку, указанному в предложении ORDER BY, может увеличить скорость поиска[53].);

* вам нужен индекс со специфическими характеристиками, не предоставляемыми данными или существующими индексами, такими как недвоичная сортировка, убывающая или возрастающая упорядоченность;

* производится группировка больших наборов записей (Индексы из одного столбца или подходящим образом упорядоченные составные индексы могут увеличить скорость группировки, условия которой заданы в сложном предложении GROUP BY.).

Вы не должны использовать индексы для столбцов, которые:

* редко используются в условиях поиска;

* являются часто изменяемыми неключевыми значениями, такими как значение времени или идентификация пользователя;

* имеют небольшое количество возможных или фактических значений в большом количестве строк;

* представляют собой двухзначное или трехзначное логическое значение.

Некоторые индексы сами заявят о себе в начальном периоде проектирования - обычно через известные вам требования сортировки, группировки, вычислений. Очень хорошей практикой является консервативный подход к созданию индексов: не создавать их, пока не станет ясным их польза. Является хорошей практикой отложить создание сомнительных индексов до того момента в разработке, когда у вас появится хороший набор тестовых данных и сведения о том, какие операции слишком медленные.

Преимущества отложенного проектирования индексов:

* уменьшение "завуалированное(tm) производительности", на которую может накладываться тестирование функциональной полноты;

* более быстрая идентификация реальных источников узких мест;

* исключение ненужного или неэффективного индексирования.

Оператор CREATE INDEX создает индекс из одного или более столбцов таблицы. Индекс из одного столбца отыскивает только один столбец в ответ на запрос, в то время как индекс из нескольких столбцов отыскивает один или более столбцов.

Синтаксис:

CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]]

INDEX имя-индекса ON имя-таблицы (столбец [, столбец ...]);

Обязательные элементы в синтаксисе CREATE INDEX следующие:

* CREATE INDEX имя-индекса - именует индекс. Идентификатор должен отличаться от идентификаторов всех других объектов базы данных за исключением идентификаторов ограничений и столбцов. Хорошая идея использовать систему имен объектов схемы, это также поможет лучшей документированности;

! ! !

ПРИМЕЧАНИЕ. Начиная с версии 1.5 и выше работает автоматическое именование индекса по имени его ограничения.

. ! .

* имя-таблицы- имя той таблицы, для которой создается индекс;

столбец [, столбец ...] - имя столбца или разделенный запятыми список имен столбцов, которые будут ключами индекса. Порядок столбцов значим для индексов. Более подробную информацию см. в разд. "Индексы из нескольких столбцов".

Следующее объявление создает неуникальный возрастающий индекс для столбца LAST_NAME (фамилия человека) в таблице PERSON. Он может быть полезным в условиях поиска типа WHERE LAST_NAME = 'Johnston' или WHERE LAST_NAME STARTING WITH 'Johns':

CREATE INDEX LAST_NAME_X ON PERSON(LAST_NAME);

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

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

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

CREATE UNIQUE INDEX STK_SIZE_COLOR_UQX

ON STOCK_ITEM (PRODUCT_ID, SIZE, COLOR);

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

Конечно, невозможно создать уникальный индекс для столбца, который уже содержит дублирующие значения. Перед определением уникального индекса используйте оператор SELECT для поиска дублирующих элементов в таблице. Например, до создания уникального индекса для PRODUCT_NAME В таблице PRODUCT следующая проверка будет показывать любые дубликаты в этом столбце:

SELECT PRODUCT_ID, UPPER(PRODUCT_NAME) FROM PRODUCT

GROUP BY PRODUCT_ID, UPPER(PRODUCT_NAME)

HAVING COUNT(*) > 1;

! ! !

ПРИМЕЧАНИЕ. Перевод значения столбца в верхний регистр, чтобы сделать поиск не чувствительным к регистру, не является необходимым с точки зрения уникальности данных. Тем не менее, если уникальность была "поломана" вводом ошибочных данных, мы можем отыскать все неправильные записи.

. ! .

Как вы поступите с дубликатами, зависит от того, что они означают в ваших бизнес- правилах, и от количества дубликатов, которые нужно уменьшить. Обычно, храни- мая процедура является наиболее эффективным способом это обработать. Хранимые процедуры подробно обсуждаются в главах 28-30.

Ключевые слова ASC[ENDING] и DESC[ENDING] определяют вертикальный порядок сортировки индекса, ASC задает сортировку индекса от меньшего к большему. Оно является значением по умолчанию и может быть опущено, DESC сортирует значения от большего к меньшему и должно быть указано, если требуется убывающий индекс. Убывающий индекс может быть полезным для запросов, которые отыскивают наибольшие значения (наибольший возраст, самый последний, самый большой и т.д.), а также при упорядоченном поиске или для выходных данных, которые должны быть отсортированы в убывающем порядке.

Следующее определение создает убывающий индекс для таблицы в базе данных employee: