Чи обмежує UNIQUE автоматичне створення ІНДЕКСУ на полі (полях)?

Чи повинен я визначити окремий індекс у emailстовпці (для цілей пошуку), або індекс додається "автоматично" разом із UNIQ_EMAIL_USERобмеженням?

CREATE TABLE IF NOT EXISTS `customer` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `first` varchar(255) NOT NULL,
  `last` varchar(255) NOT NULL,
  `slug` varchar(255) NOT NULL,
  `email` varchar(255) NOT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UNIQ_SLUG` (`slug`),
  UNIQUE KEY `UNIQ_EMAIL_USER` (`email`,`user_id`),
  KEY `IDX_USER` (`user_id`)
) ENGINE=InnoDB;

EDIT : як запропонував Корбін, я запитував EXPLAIN SELECT * FROM customer WHERE email = 'address'на порожньому столі. Це результат, я не знаю, як його інтерпретувати:

id select_type type possible_keys key  key_len ref  rows Extra
1  SIMPLE      ALL  NULL          NULL NULL    NULL 1    Using where

Під час додавання IXD_EMAIL до таблиці відображається той самий запит:

id select_type type possible_keys key       key_len ref   rows Extra
1  SIMPLE      ref  IDX_EMAIL     IDX_EMAIL 257     const 1    Using where

mysql sql indexing

— gremo
джерело

УНІКАЛЬНЕ обмеження технічно не вимагає індексу ... але не впевнений, як стандарт його визначає, або MySQL (який сервер, до речі?) Реалізує його. Все, що я можу швидко знайти в MySQL вручну, це "УНІКАЛЬНИЙ індекс створює обмеження таким чином, що всі значення в індексі повинні бути різними."

Вам потрібно впровадити та протестувати з індивідуальними індексами проти покриття (AKA складений - більше одного стовпця) індексів. Це залежить від використання та даних.

— OMG Ponies

Я впевнений на 99%, що він справді створює індекс. Просто створіть таблицю з унікальним елементом, а потім поясніть пояснити вибірку з де.

— Корбін,

@Corbin зробив це, як я повинен інтерпретувати результат?

— gremo

Чи використовувало воно унікальне обмеження як індекс? Можливо, вам доведеться використовувати значно велику таблицю, а може просто зробити сканування таблиці.

— Корбін,

115

Унікальний ключ є окремим випадком індексу, діючи як звичайний індекс з доданою для перевірки унікальності. За допомогою SHOW INDEXES FROM customerви можете побачити, що ваші унікальні ключі насправді є індексами типу B-дерева.

Композитний індекс на (email, user_id)досить, вам не потрібен окремий індекс тільки по електронній пошті - MySQL може використовувати самі ліві частини складеного індексу. Можуть бути випадки, коли розмір індексу може уповільнити ваші запити, але вам не слід турбуватися про них, доки фактично не натрапите на них.

Що стосується тестування використання індексу, спочатку слід заповнити таблицю деякими даними, щоб оптимізатор думав, що насправді варто використовувати цей індекс.

— piotrm
джерело

Тож EXPLAINтест показує хибні значення через порожню таблицю?

— gremo

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

— piotrm

Гаразд, знайшов фокус. Коли обмеження визначається за допомогою user_idспочатку, а потім emailвоно не відображається в EXPLAIN. Чи знаєте ви про це?

— gremo

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

— piotrm