Sollte ich Indizes für eine Viele-zu-viele-Datenbanktabelle verwenden?

Question

macht es Sinn Indizes für eine Tabelle mit den folgenden Spalten genannt user_movies zu erstellen:

User_id movie_id

Es wird viel mehr Lese als Einfügen oder auf diese Tabelle zu aktualisieren, aber ich bin nicht sicher, was machen. Außerdem: Reicht es aus, in dieser Situation einen Primärschlüssel wegzulassen?

Answer 1

Die richtige Definition für diese Tabelle ist wie folgt:

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; 

Notice „Primärschlüssel“ eine Einschränkung ist, keine Spalte. Es ist die beste Vorgehensweise, einen Primärschlüssel Constraint in jeder Tabelle zu haben. Verwechseln Sie die Primärschlüsseleinschränkung nicht mit einer automatisch generierten Pseudo-Schlüsselspalte.

In MySQL erzeugt die Deklaration eines Fremdschlüssels oder Primärschlüssels implizit einen Index. Ja, diese sind vorteilhaft.

Answer 2

Ich würde beide Spalten separat indizieren und ja Sie können den Primärschlüssel beseitigen.

Answer 3

Wenn Sie eine solche "Join-Tabelle" verwenden, verwenden Sie wahrscheinlich einige Joins in Ihren Abfragen - und diese werden wahrscheinlich von einem Index für jede dieser beiden Spalten profitieren (was zwei separate Indizes bedeutet) .

Answer 4

Ich habe immer gehört, dass Sie einen eindeutigen Index für beide Spalten erstellen sollte, zunächst eine Möglichkeit (user_id + movie_id), dann in die andere Richtung (movie_id + user_id). Es funktioniert etwas schneller (nicht viel, etwa 10-20%) in meiner Anwendung mit einigen schnellen und schmutzigen Tests.

Es stellt auch sicher, dass Sie nicht zwei Zeilen haben, die die gleichen movie_id an die gleiche user_id binden (was gut sein könnte, aber vielleicht nicht immer).