Делает ли поле уникальным сделать его индексированным?

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

В частности, я работаю с Apache Derby для создания прототипов, хотя я, вероятно, перенесу его в MySQL в ближайшем будущем. Я также надеюсь, что в стандарте SQL может быть что-то, что об этом говорит.

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

--РЕДАКТИРОВАТЬ--

Мой оригинальный ответ (ниже), вероятно, вам вообще не нужен, потому что он не затрагивает вопрос об uniqueограничениях. Как уже говорили другие, эти ограничения обычно реализуются с подразумеваемым уникальным индексом. В особых случаях это может быть не так (например, disable novalidateдля Oracle).

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

--END EDIT--

Вы сказали: «Я бы предпочел иметь бесполезный индекс, чем иметь время вставки O (n)», но в общем случае базы данных не имеют времени вставки O (n). Есть два случая для рассмотрения:

1. Обычная таблица с индексами или без них:

   Новые строки сбрасываются в верхней части кучи. СУБД, вероятно, рассматривает только 1 блок, поэтому не только O (1), но и очень маленький O (1).

   Если таблица имеет индексы, к каждому из них будет добавлен указатель на строку. Обычно это операция O (log (n)).

2. Таблица с какой-либо кластеризацией, например, организованная индексная таблица или кластер для Oracle, или кластеризованный индекс для SQL Server и другие:

   Новые строки вставляются в конкретный блок, что может привести к разделению или переполнению блока, но что бы ни случилось, это все равно O (log (n)) или лучше , вызванное b-деревом или аналогичной структурой, используемой для поиска блока.

ПЕРВИЧНЫЙ КЛЮЧ> = УНИКАЛЬНЫЙ> = ИНДЕКС == КЛЮЧ

Данные InnoDB заказываются PK. MyISAM PK действует так же, как UNIQUE.

INSERT должен добавить «строку» к каждому индексу (любого вида), который у вас есть. Это займет некоторое время. (Обычно не хватает времени, чтобы иметь значение.) Все индексы хранятся в формате BTree. Блоки MyISAM BTree составляют 1 КБ; InnoDB использует 16 КБ.

Вставка в InnoDB обновляет PK и данные одновременно.

Вставка в MyISAM обычно «добавляет» данные в .MYD. Отдельно добавляется строка в PK (если есть).

INSERT должен сначала проверить, что для любого ПЕРВИЧНОГО или УНИКАЛЬНОГО ключа нет дублирующего ключа. Это делается с помощью индекса. И, следовательно, почему UNIQUE и FOREIGN KEY CONSTRAINTs действительно строят индексы. Это O (logN), но обычно процессор, а не I / O, потому что при эффективном кэшировании.

Чтобы ответить на вопрос, выделенный жирным шрифтом: Да, если поле уникально, оно индексируется как первичный ключ. Фактически, я обсуждал это в другом вопросе, касающемся того, что первичные ключи имеют свое собственное имя, чтобы отличать его от других уникальных (потенциальных) ключей .

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

Возможно, вам никогда не придется искать это поле, но MySQL непременно должен будет указать его путь, чтобы определить допустимость ключей и определить, как выполнять операции ON DELETE CASCADE и ON UPDATE CASCADE.

Индекс UNIQUE просто гарантирует уникальность кортежей (синглетонов, пар, триплетов, ..., n-кортежей и т. Д.) В каждой строке таблицы.

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