Каковы хорошие кандидаты для создания индексов рядом с pk и уникальными столбцами?

Question

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

Answer 1

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

Answer 2

Oracle автоматически создает уникальный индекс для столбца (или набора столбцов) при создании ограничения UNIQUE. Индекс используется при применении ограничения.

Oracle также автоматически создает уникальный индекс для столбца (или набора столбцов) при создании ограничения PRIMARY KEY. Этот индекс также используется для принудительного применения ограничения. Существует небольшая, но некоторая разница между ограничением PRIMARY KEY и ограничением UNIQUE.

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

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

Порядок столбцов в многостолбцовых индексах должен быть тщательно продуман. Во-первых, многостолбцовый индекс совсем не работает, как отдельные одностолбцовые индексы в одних и тех же столбцах, но Oracle редко (если вообще вообще, особенно без подсказок) использует более одного индекса для одного запроса (индексы BITMAP являются возможное исключение). Если у вас обычно есть столбцы A, B и C в предложении WHERE, вы можете захотеть индексировать по A, B и C. Однако, если вы также часто используете A и C в предложении WHERE, без B, то вы бы вероятно, вы хотите заказать столбцы в вашем индексе как A, C, B. Такой индекс также можно использовать, когда в предложении WHERE присутствует только A. Проще говоря, Oracle может использовать подмножество столбцов в индексе только с помощью префикса индекса, а не случайного ассортимента столбцов в индексе.

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

В качестве заключительного замечания, EXPLAIN PLAN - ваш друг. Если вы обнаружите, что часто выполняемые запросы выполняют полное сканирование таблиц в больших таблицах, индекс может быть в порядке.

Answer 3

Ваши запросы.

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

Answer 4

Несколько хороших идей здесь. Обратите особое внимание на запросы с проблемами производительности и попробуйте создать индексы с высокой селективностью.

Кроме того, неплохо бы контролировать использование индекса:

ALTER INDEX <index> MONITORING USAGE;

Периодически вы можете проверять значение v $ object_usage.used, чтобы увидеть, обращался ли к индексу когда-либо доступ с момента включения мониторинга:

SELECT i.table_name, i.index_name, i.tablespace_name, bytes/1000000 mb, u.used
  FROM dba_indexes i JOIN dba_segments ON (i.index_name = segment_name)
          LEFT OUTER JOIN v$object_usage u ON (i.index_name = u.index_name)
 WHERE i.owner = <schema>
   AND NVL(USED,'NO') = 'NO'
   AND i.table_name = <table of interest>
 ORDER BY bytes DESC;

Мне удалось сократить несколько индексов с информацией, которую она предоставляет.

Answer 5

Полностью зависит от того, какие запросы вы выполняете к таблице.

К вероятным кандидатам относятся:

1. Поля, участвующие в объединении
2. Поля, которые являются частью предложения WHERE
3. Поля часть ORDER BY

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

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

Answer 6

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