Индексный вопрос: выберите * с предложением WHERE. Где и как создать индекс - PullRequest
0 голосов
/ 17 мая 2010

Я работаю над оптимизацией некоторых моих запросов, и у меня есть запрос, который заявляет: выберите * из SC, где c_id = "+ c_id" Схема ** SC ** выглядит так:

SC (  c_id int not null,  date_start date not null, date_stop date not null, r_t_id int not null,  nt int,  t_p decimal,   PRIMARY KEY (c_id, r_t_id, date_start, date_stop));

Моя немедленная заявка на то, как должен быть создан индекс, является индексом покрытия в следующем порядке:

INDEX(c_id, date_start, date_stop, nt, r_t_id, t_p)

Причину этого заказа я основываю на:

Предложение WHERE выбирает из c_id, делая его первым порядком сортировки. Затем, date_start и date_stop, чтобы указать вид «диапазона», который будет определен в этих параметрах Далее, нт, потому что он выберет нт Затем r_t_id, потому что это идентификатор для определенного типа моей таблицы r_t И последний t_p, потому что это просто информация.

Я не знаю, нужно ли вообще заказывать его определенным образом, когда это оператор SELECT ALL. Я должен сказать, что SC не самая большая таблица. Я могу сказать, сколько строк в нем содержится, но оценка может быть между <10 и 1000. </p>

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

Не знаю, изменится ли он, но я использую базу данных IBM DB2 версии 9.7

С уважением

Mestika

1 Ответ

0 голосов
/ 27 мая 2010

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

...