Когда вы используете каждый тип индекса MySQL?
- ПЕРВИЧНЫЙ - Столбцы первичного ключа?
- УНИКАЛЬНО - Внешние ключи?
- ПОКАЗАТЕЛЬ - ??
Улучшают ли индексированные столбцы производительность действительно больших таблиц?
Когда вы используете каждый тип индекса MySQL?
Улучшают ли индексированные столбцы производительность действительно больших таблиц?
Первичный ключ, как следует из названия, является основным ключом таблицы и должен быть столбцом, который обычно используется для выбора строк этой таблицы. Первичный ключ - это всегда уникальный ключ (уникальный идентификатор). Первичный ключ не ограничен одним столбцом, например, в справочных таблицах (многие ко многим) часто имеет смысл иметь первичный ключ, включающий два или более столбца.
Уникальный индекс гарантирует, что ваша СУБД не принимает повторяющиеся записи для этого столбца. Вы спросите: «Внешние ключи?» НЕТ! Это было бы бесполезно, поскольку внешние ключи по определению склонны к дублированию (один-ко-многим, многие-ко-многим).
Дополнительные индексы могут быть размещены в столбцах, которые часто используются для SELECTS (и JOINS), что часто имеет место для внешних ключей. Во многих случаях запросы SELECT (и JOIN) будут выполняться быстрее, если внешние ключи проиндексированы.
Однако обратите внимание, что, как пояснил SquareCog, индексы обновляются при любых изменениях данных, поэтому да, добавление дополнительных индексов может привести к снижению производительности INSERT / UPDATE. Если индексы не обновлялись, вы получали бы разную информацию в зависимости от того, решил ли оптимизатор выполнить ваш запрос по индексу или необработанной таблице - крайне нежелательная ситуация.
Это означает, что вам следует внимательно оценивать использование индексов. На основании этого можно быть уверенным в одном: Следует избегать неиспользуемых индексов, соответственно. удалено!
Я не так хорошо знаком с MySQL, но считаю, что для большинства серверов баз данных справедливо следующее. Индекс - это сбалансированное дерево, которое используется, чтобы позволить базе данных сканировать таблицу на предмет заданных данных. Например, у вас есть следующая таблица.
CREATE TABLE person (
id SERIAL,
name VARCHAR(20),
dob VARCHAR(20)
);
Если вы создали индекс для поля «имя», это создаст сбалансированное дерево для этих данных в таблице для столбца имени. Сбалансированные древовидные структуры данных позволяют ускорить поиск результатов (см. http://www.solutionhacker.com/tag/balanced-tree/).
Однако следует отметить, что индексирование столбца позволяет выполнять поиск только по данным, хранящимся в базе данных. Например:
Это не сможет выполнять поиск по индексу и вместо этого будет выполнять последовательное сканирование таблицы, вызывая UPPER () для каждой строки столбца: имя в таблице.
select *
from person
where UPPER(name) = "BOB";
Это также будет иметь следующий эффект, потому что индекс будет отсортирован, начиная с первой буквы. Однако при замене поискового запроса на "% B" будет использоваться индекс.
select *
from person
where name like "%B"
Индексы улучшат производительность на больших таблицах. Обычно первичный ключ имеет индекс на основе ключа. Обычно уникальный.
Полезно добавить индексы к полям, которые также используются для поиска по множеству объектов, например, по названию улицы или фамилии, так как это опять же улучшит производительность. Не обязательно быть уникальным.
Внешние ключи и уникальные ключи больше предназначены для поддержания целостности ваших данных в порядке. Чтобы у вас не было повторяющихся первичных ключей и чтобы в ваших дочерних таблицах не было данных для удаленного родителя.
PRIMARY определяет первичный ключ, да.
UNIQUE просто определяет, что указанное поле должно быть уникальным, оно не имеет ничего общего с внешними ключами.
INDEX создает индекс для указанного столбца и, да, он улучшает производительность для больших таблиц, сортировка и поиск чего-либо в этом столбце может быть намного быстрее, если вы используете индексирование.
Чем больше таблица, тем больше выгода от использования индекса. Обратите внимание, что индексы замедляют операции вставки (и, возможно, обновления), поэтому убедитесь, что вы не индексируете слишком много полей.