Чи робить поле унікальним, робить його індексованим?

Якщо я uniqueобмежую поле, чи потрібно мені також робити індекс на цьому полі, щоб отримати масштабований час вставки? Або це зроблено для мене (навіть якщо індекс, який він використовує, не є загальнодоступним?)

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

У мене ніколи не буде потреби в пошуку за цим полем, тому я краще не буду робити марний індекс. Але я б скоріше мав марний індекс, ніж мав час O(n)вставки.

--EDIT--

Моя оригінальна відповідь (нижче), напевно, вам зовсім не корисна, оскільки вона не стосується питання uniqueобмежень. Як зазначають інші, ці обмеження зазвичай реалізуються з маючи на увазі унікальний індекс. В окремих випадках це може бути неправдою (наприклад, disable novalidateдля Oracle).

Питання може бути таким: чи можливо набути унікальності без індексу? Взагалі відповідь - ні, хоча в деяких випадках індекс кластера означатиме, що індекс і таблиця є одним і тим же об'єктом.

--END EDIT--

Ви сказали: "Я б швидше мав непотрібний індекс, ніж мав час вставки O (n).", Але загалом у базах даних немає часу на введення O (n). Слід розглянути два випадки:

1. Нормальна таблиця з індексами або без них:

   Нові ряди скидаються у верхній частині купи. RDBMS, ймовірно, дивиться лише на 1 блок, тому не просто O (1), але дуже малий O (1).

   Якщо таблиця має індекси, до кожного додається покажчик на рядок. Зазвичай це операція O (log (n)).

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

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

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

Дані InnoDB упорядковуються ПК. MyISAM PK діє так само, як УНІКАЛЬНО.

INSERT повинен додати "рядок" до кожного індексу (будь-якого виду), який у вас є. Це займає деякий час. (Зазвичай на питання не вистачає часу.) Індекси зберігаються у форматі BTree. Блоки MyISAM BTree - 1 КБ; InnoDB використовує 16 КБ.

Вставлення в InnoDB оновлює ПК та дані одночасно.

Вставлення в MyISAM зазвичай "додає" дані до .MYD. Окремо він додає рядок до ПК (якщо такий є).

INSERT спочатку повинен переконатися, що немає жодного повторюваного ключа для жодного ПРИМІТНОГО або УНІКАЛЬНОГО ключа. Це робиться за допомогою індексу. І, отже, чому УНІКАЛЬНІ та ЗОВНІШНІ КЛЮЧОВІ ВИСНОВКИ дійсно будують індекси. Це O (logN), але зазвичай процесор, а не введення / виведення, тому що якщо ефективне кешування.

Щоб відповісти на запитання жирним шрифтом: Так, створення поля унікальним робить його індексом як первинний ключ. Насправді я обговорював це в іншому запитанні стосовно первинних ключів, які мають власну назву, щоб відрізнити його від інших унікальних (кандидатських) ключів .

Що стосується обмежень, то для вас створюються індекси, щоб встановити парадигму обмежень. Ви повинні мати змогу видаляти повторювані індекси, навіть UNIQUE ключі до тих пір, поки створене вами обмеження не посилається на інші Унікальні ключі, які ви особисто створили, окрім парадигми обмеження.

Можливо, вам ніколи не доведеться шукати це поле, але MySQL обов'язково повинен буде визначити дійсність ключів і визначити, як слід виконувати операції ON DELETE CASCADE і ON UPDATE CASCADE.

Індекс UNIQUE просто гарантує унікальність кортежів (одиночні кнопки, пари, трійки, ..., n-кортежі тощо) у кожному рядку таблиці.

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