Изучаем.SQL

Query OK, 3 rows affected (0.04 sec)

Records: 3 Duplicates: 0 Warnings: 0

В SQL Server и Oracle Database при создании индекса нужно только добавить ключевое слово unique:

CREATE UNIQUE INDEX dept_name_idx

ON department (name);

При наличии такого индекса в случае попытки добавить еще один от дел под названием 'Operations' будет получена ошибка:

mysql> INSERT INTO department (dept_id, name)

> VALUES (999, 'Operations');

ERROR 1062 (23000): Duplicate entry 'Operations' for key 2

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

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

Кроме уже представленных индексов по одному столбцу, можно созда вать индексы, охватывающие несколько столбцов. Если, например, требуется проводить поиск сотрудников по имени и фамилии, можно сделать индекс сразу для двух столбцов:

mysql> ALTER TABLE employee

> ADD INDEX emp_names_idx (lname, fname);

Query OK, 18 rows affected (0.10 sec) Records: 18 Duplicates: 0 Warnings: 0

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

Поэтому при создании составных индексов (multiple column indexes) необходимо тщательно продумать, какой столбец указывать первым, а какой вторым и т. д., чтобы индекс был максимально полезным. Од нако следует помнить, что если требуется обеспечить адекватное вре мя ответа, ничто не мешает создать несколько индексов, используя тот же набор столбцов, но в другом порядке.

сервер просматривает ассоциированную таблицу и извлекает дополни тельную информацию, запрашиваемую пользователем. Рассмотрим следующий запрос:

mysql> SELECT emp_id, fname, lname

> FROM employee

> WHERE emp_id IN (1, 3, 9, 15, 22);

+ + + + | emp_id | fname | lname | + + + +

+ + + + 4 rows in set (0.00 sec)

Для этого запроса сервер может использовать в качестве индекса пер вичный ключ для столбца emp_id, чтобы найти местоположение сотруд ников с ID 1, 3, 9, 15 и 22 в таблице employee, и затем просмотреть каж дую из пяти строк, чтобы извлечь значения столбцов имени и фамилии.

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

Запрос, агрегирующий остатки на счетах для определенных клиентов, выглядит так:

mysql> SELECT cust_id, SUM(avail_balance) tot_bal

> FROM account

> WHERE cust_id IN (1, 5, 9, 11)> GROUP BY cust_id;

+ + + | cust_id | tot_bal | + + +

|1 | 4557.75 |

С помощью выражения explain (объяснить) рассмотрим, как оптими затор запросов MySQL принимает решение об обработке запроса. Сер вер не будет выполнять запрос, а покажет план его выполнения:

*************************** 1. row ***************************

id: 1 select_type: SIMPLE

table: account type: index

possible_keys: fk_a_cust_id key: fk_a_cust_id

key_len: 4 ref: NULL

rows: 24

Extra: Using where 1 row in set (0.00 sec)

Каждый сервер БД включает инструменты, позволяющие уви деть, как оптимизатор запросов обрабатывает SQL выражение. В SQL Server увидеть план выполнения перед выполнением SQL выражения позволяет выражение set showplan_text on. В Oracle Database есть выражение explain plan, записывающее план выполнения в специальную таблицу plan_table.

Если не вдаваться в детали, то план выполнения сообщает следующее:

•Индекс fk_a_cust_id используется для поиска строк таблицы account, которые удовлетворяют условию блока where.

•После прочтения индекса ожидается, что сервер просмотрит все 24 строки таблицы account для сбора данных о доступных остатках, поскольку он не знает, что могут существовать другие клиенты, кроме клиентов с ID 1, 5, 9 и 11.

Индекс fk_a_cust_id – еще один индекс, автоматически сгенерирован ный сервером, но на этот раз из за ограничения внешнего ключа, а не ограничения первичного ключа (более подробно об этом позже в этой главе). Индекс fk_a_cust_id создан для столбца account.cust_id, таким образом, сервер использует его для определения местоположения кли ентов с ID 1, 5, 9 и 11 в таблице account, а затем посещает эти строки для извлечения и агрегирования данных по доступным остаткам.

Далее добавим новый индекс с названием acc_bal_idx для обоих столб цов cust_id и avail_balance:

mysql> ALTER TABLE account

> ADD INDEX acc_bal_idx (cust_id, avail_balance);

Query OK, 24 rows affected (0.03 sec) Records: 24 Duplicates: 0 Warnings: 0

Теперь, имея этот индекс, посмотрим, как оптимизатор будет обраба тывать тот же запрос:

*************************** 1. row ***************************

id: 1 select_type: SIMPLE

table: account type: range

possible_keys: acc_bal_idx key: acc_bal_idx

key_len: 4 ref: NULL

rows: 8

Extra: Using where; Using index 1 row in set (0.01 sec)

Сравнение двух планов выполнения дает следующие различия:

•Вместо индекса fk_a_cust_id оптимизатор использует новый индекс acc_bal_idx.

•Оптимизатор ускоряет свою работу, поскольку теперь ему надо об работать только восемь строк вместо 24.

•Для обеспечения результатов запроса таблица account не нужна (обозначена через Using index в столбце Extra).

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

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

Обратная сторона индексации

Если индексы – это так замечательно, почему бы не индексировать все подряд? Чтобы понять, почему большее количество индексов не всегда хорошо, надо помнить, что каждый индекс – это таблица (особого ти па, но все равно таблица). Поэтому при каждом добавлении или удале нии строки из таблицы все ее индексы должны быть модифицирова ны. При обновлении строки все задействованные индексы столбца или столбцов тоже должны изменяться. Следовательно, чем больше индек сов, тем больше работы приходится выполнять серверу для обновле ния всех объектов схемы. А это очень замедляет процесс.

Индексам требуется некоторое количество памяти, а также некоторое внимание администраторов, поэтому наилучшая стратегия – добавлять

Создание ограничений

Обычно ограничения создают одновременно с ассоциированной табли цей посредством выражения create table. Для иллюстрации приведем пример из сценария формирования схемы для БД, используемой в ка честве примера к этой книге:

CREATE TABLE product

(product_cd VARCHAR(10) NOT NULL, name VARCHAR(50) NOT NULL,

product_type_cd VARCHAR (10) NOT NULL, date_offered DATE,

date_retired DATE,

CONSTRAINT fk_product_type_cd FOREIGN KEY (product_type_cd) REFERENCES product_type (product_type_cd),

CONSTRAINT pk_product PRIMARY KEY (product_cd)

);

Таблица product включает два ограничения: первое определяет столбец product_cd как первичный ключ таблицы, а второе – столбец product_ type_cd как внешний ключ к таблице product_type. Альтернативный ва риант: таблицу product можно было создать без ограничений, а ограни чения первичного и внешнего ключей добавить позже посредством вы ражений alter table:

ALTER TABLE product

ADD CONSTRAINT pk_product PRIMARY KEY (product_cd);

ALTER TABLE product

ADD CONSTRAINT fk_product_type_cd FOREIGN KEY (product_type_cd)

REFERENCES product_type (product_type_cd);

Если требуется убрать ограничения первичного или внешнего ключей, можно опять воспользоваться выражением alter table, только в этом случае задается drop, а не add:

ALTER TABLE product

DROP PRIMARY KEY;

ALTER TABLE product

DROP FOREIGN KEY fk_product_type_cd;

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

Ограничения и индексы

Как было показано в этой главе ранее, иногда создание ограничений включает автоматическое формирование индекса. Однако серверы БД ведут себя по разному в зависимости от связи между ограничениями и индексами. В табл. 13.1 показаны связи между ограничениями и ин дексами в MySQL, SQL Server и Oracle Database.

Таблица 13.1. Формирование ограничений

Следовательно, MySQL формирует новый индекс, чтобы реализовать ограничения первичного ключа, внешнего ключа и уникальности. SQL Server формирует новый индекс для ограничений первичного ключа и уникальности, а для ограничений внешнего ключа – нет. Oracle Da tabase использует такой же подход, как и SQL Server, за тем исключе нием, что Oracle для введения в действие ограничений первичного клю ча и уникальности будет использовать существующий индекс (если есть подходящий). Хотя ни SQL Server, ни Oracle Database не формиру ют индекс для ограничения внешнего ключа, документация обоих сер веров рекомендует создавать индекс для каждого внешнего ключа.

Каскадные ограничения

Если при наличии ограничений внешнего ключа пользователь пытает ся вставить новую строку или изменить существующую и при этом по лучается, что столбец внешнего ключа не имеет соответствующего зна чения в родительской таблице, сервер формирует ошибку. Для иллю страции рассмотрим данные таблиц product и product_type:

mysql> SELECT product_type_cd, name

> FROM product_type;

+ + +

+ + + + | product_type_cd | product_cd | name | + + + +