Должен ли я использовать индексы для таблицы базы данных «многие ко многим»?

Question

имеет ли смысл создавать индексы для таблицы с именем user_movies со следующими столбцами:

user_id movie_id

Будет гораздо больше чтения, чем вставка или обновление в этой таблице, но я не уверен, что делать. Также: достаточно ли в этой ситуации опустить первичный ключ?

Answer 1

Правильное определение для этой таблицы следующее:

CREATE TABLE user_movies (
  user_id INT NOT NULL,
  movie_id INT NOT NULL,
  PRIMARY KEY (user_id, movie_id),
  FOREIGN KEY (user_id) REFERENCES users(user_id),
  FOREIGN KEY (movie_id) REFERENCES movies(movie_id)
) ENGINE=InnoDb;

Обратите внимание, что «первичный ключ» - это ограничение, а не столбец.Лучше всего иметь первичный ключ ограничение в каждой таблице.Не путайте ограничение первичного ключа с автоматически генерируемым столбцом псевдоключа.

В MySQL объявление внешнего ключа или первичного ключа неявно создает индекс.Да, это выгодно.

Answer 2

Я всегда слышал, что вы должны создать уникальный индекс для ОБА столбцов, сначала в одну сторону (user_id + movie_id), а затем в другую сторону (movie_id + user_id). Это работает немного быстрее (не очень, около 10-20%) в моем приложении с некоторым быстрым и грязным тестированием.

Это также гарантирует, что вы не можете иметь две строки, которые связывают один и тот же movie_id с одним и тем же user_id (что может быть хорошо, но, возможно, не всегда).

Answer 3

Я бы проиндексировал оба столбца по отдельности, и да, вы можете исключить первичный ключ.

Answer 4

Если вы используете такую ​​«таблицу соединений», вы, вероятно, будете использовать в своих запросах некоторые объединения - и для них, вероятно, будет полезен индекс для каждого из этих двух столбцов (что означает два отдельных индекса).