Как правильно индексировать таблицу сопоставления многих-многих?

Question

В таком типичном расположении, как многие ...

Movies       Actors       Movies_Actors
------       ------       -------------
movie_ID     actor_ID     FK_movie_ID
title        name         FK_actor_ID

... как индексировать таблицу ассоциации ('Movies_Actors') для оптимальной скорости чтения?

Обычно я вижу, что это делается только с помощью составного первичного ключа в таблице ассоциации, например:

CREATE TABLE Movies_Actors (
  FK_movie_ID INTEGER,
  FK_actor_ID INTEGER,
  PRIMARY KEY (FK_movie_ID, FK_actor_ID)
)

Однако похоже, что индекс будет полезен только при поиске и movie_ID, и actor_ID (хотя я не уверен, работает ли составной индекс для отдельных столбцов) .

Поскольку «какие актеры в фильме X» и «в каких фильмах снялся актер Y» будут общими запросами для этой таблицы, похоже, что для быстрого поиска актеров и фильмов в каждом столбце должен быть отдельный индекс самостоятельно. Эффективно ли это делает составной индекс? Если нет, то составной индекс в этой таблице кажется бессмысленным. А если составной индекс не имеет смысла, что делать с первичным ключом? Ключ-кандидат, очевидно, является составной частью двух столбцов, но если полученный составной индекс является бессмысленным (не должно быть?), Это кажется пустой тратой.

Кроме того, эта ссылка добавляет некоторую путаницу и указывает на то, что было бы даже полезно указать два составных индекса ... один из них как (FK_movie_ID, FK_actor_ID), а другой в обратном порядке, как (FK_actor_ID, FK_movie_ID), с выбором которого является первичным ключом (и, следовательно, обычно кластеризованным) и который является «просто» уникальным составным индексом, основанным на том, какое направление запрашивается больше.

Какая настоящая история? Эффективно ли составной индекс автоматически индексирует каждый столбец для поиска по одному или другому? Должна ли таблица оптимальных (по скорости чтения, а не по размеру) иметь составной индекс в каждом направлении и по одному на каждый столбец? Что такое закулисные механики?

---

РЕДАКТИРОВАТЬ: Я нашел этот связанный вопрос, который по какой-то причине я не нашел перед публикацией ... Как правильно индексировать таблицу ссылок для соединения многие-ко-многим в MySQL?

Answer 1

(хотя я не уверен, работает ли составной индекс для отдельных столбцов).

Да, может.Но только префикс: http://use -the-index-luke.com / sql / where-clause / оператор-equals / сцепленные ключи

Кроме того, этоссылка добавляет некоторую путаницу и указывает, что может быть даже полезно указать два составных индекса ... один из них как (FK_movie_ID, FK_actor_ID), а другой наоборот (FK_actor_ID, FK_movie_ID),

Это действительно то, что нужно сделать.

Взять один в качестве индекса кластеризации, а другой - в качестве некластеризованного индекса, который в любом случае будет включать ключ индекса кластеризации - следовательно, нет необходимости снова включать этот столбец (thxJNK).

CREATE CLUSTERING INDEX a on Movies_Actors (fk_movie_id, fk_actor_id);
CREATE NONCLUSTERING INDEX b on Movies_Actors (fk_actor_id);

Что такое настоящая история?

http://Use -The-Index-Luke.com / :)

Эффективно ли составной индекс автоматически индексирует каждый столбец для поиска по одному или другому?

Нет.Только префикс индекса.Если у вас есть индекс (a, b, c), запрос a =?и б =?можете использовать индекс.Однако с =?не может, и не может б =?и c =?.

Должна ли таблица оптимальных (по скорости чтения, а не по размеру) иметь составной индекс в каждом направлении и по одному в каждом столбце?

Есливам нужно объединиться в обоих направлениях: да («составной указатель в каждом направлении») и нет («по одному на каждый столбец»).

Что такое закулисная механика?

Ну, опять та же ссылка.

Говоря о SQL Server, вы можете со временем также рассмотреть индексированное представление.Это своего рода предварительное присоединение.Два индекса, как указано выше, также могут быть достаточно быстрыми.

Answer 2

В SQL Server составной индекс можно использовать для поиска по одному полю только для первого столбца .Это означает, что у вас должен быть дополнительный индекс одного поля на FK_actor_id, если в этом поле будут выполняться поиск без FK_Movie_id в том же запросе.