Composite-Schlüssel VS Primärschlüssel + nicht eindeutigen Index

Question

Hier ist, was ich habe:

table content : cat_id product_id data1 data2 etc.
die Kategorien offensichtlich nicht eindeutig sind. Die Produkt-IDs sind einzigartig.

2 queries : 1 -- SELECT * WHERE cat_id = :cat - must be as quick as possible 2 -- SELECT * WHERE product_id = :prodId In second select, I can add : AND cat_id = :cat

Was ist effizienter?

• 1 - index (nicht eindeutig) auf cat_id (gut für select 1)
• 2 - Primärschlüssel auf product_id (unique -> sehr gut für ausgewählten 2)
• 3 - Index (nicht unique) auf cat_id + PK auf product_id (gut für 1 & 2 getrennt)
• 4 - eindeutige Einschränkung mit composite [cat_id + product_id] (gut für 1 & 2 zusammen)
• 5 - das gleiche wie 4, b ut Definition der Verbund als PK
• 6 - Kunstoff (4 oder 5) + Einzelindex/PK

Informationen, werde ich rund 20 Produkte in jeder Kategorie und viele Kategorien (etwa 3000) haben - Und (wie es einzigartig in der Tabelle ist) EIN Produkt gehört nur zu einer Kategorie - In der Tat, das ist nicht wirklich Katzen und Produkte, das ist für die Einfachheit der Erklärung;)

danke!

Answer 1

Eine Datenbank ohne Primärschlüssel ist nur zur Hälfte verkleidet und Ihrer Meinung nach ist product_id ein idealer Kandidat für einen Primärschlüssel, also wählen Sie das aus. Der Primärschlüssel wird in

SELECT * WHERE product_id = :prodId 

verwendet werden Es spielt keine Rolle, ob and cat_id = :cat_id ein Teil der Abfrage wird oder nicht, es sei denn Sie haben Tausende von cat_ids mit jedem product_id verbunden.

Wählen Sie dann einen Index für cat_id. Dies wird verwendet werden

SELECT * WHERE cat_id = :cat 

Dies wird sehr schnell sein, wenn die Kardinalität der Daten gut ist. Das bedeutet, dass es eine breite Verteilung von cat_id s in der Tabelle gibt. Der Index cat_id wird nicht in der ersten Abfrage verwendet. So haben Sie zwei verschiedene Indizes und beide Abfragen können sehr schnell erwartet werden.

Seit [cat_id+product_id] != [product_id+cat_id] wenn es um Indexierung geht, wenn Sie nur einen zusammengesetzten Index haben, wird der eine oder andere langsam sein.

Angenommen, wir hätten einen zusammengesetzten Index für (cat_id, product_id) jetzt die folgende Abfrage kann diesen Index nicht verwenden.

SELECT * FROM tablename WHERE product_id = :prodId 

Aber beide diese Abfragen verwenden können, die (cat_id, product_id) Index

SELECT * FROM tablename WHERE cat_id = :cat_id and product_id = :prodId 
SELECT * FROM tablename WHERE cat_id = :catId 

Also zusammenfassend. Wähle 1 und 2.Aber wenn die Anzahl der cat_id s sind klein oder es gibt viele cat_ids mit jedem product_id verbunden wählen Sie 4, aber stellen Sie sicher, dass der Primärschlüssel auch vorhanden ist.

Answer 2

Wenn diese Ihre nur zwei Anfragen:

SELECT * FROM tablename WHERE cat_id = :cat_id and product_id = :prodId 
SELECT * FROM tablename WHERE cat_id = :cat_id 

und Sie haben eine andere Art und Weise, um sicherzustellen, dass product_id ist UNIQUE, dann müssen Sie nur:

PRIMARY KEY(cat_id, product_id) 

Es ist optimal für beideSELECTs.

Es ist besser als INDEX(cat_id), weil (1) sekundäre Schlüssel ihre Arbeit mit einem PK-Lookup beenden müssen, und (2) alle Cat-Zeilen sind benachbart, dadurch effizienter.

Wenn product_id ist eigentlich ein AUTO_INCREMENT, fügen Sie dann

INDEX(product_id) 

Nein, Sie müssen UNIQUE nicht sagen (es sei denn, Sie sind anfällig absichtlich doppelte product_ids einfügen zu versuchen). Die einzige Sache, die AI erfordert, ist, dass die ID in einige Index zuerst ist, so dass es das Äquivalent von SELECT max(id) tun kann, wenn mysqld neu gestartet wird.

Meine Empfehlungen gelten unabhängig von der Größe der Tabelle.

Die Reihenfolge der Klauseln in WHERE tut nicht Angelegenheit.

JOINs nicht erfordert etwas besonderes. Es ist etwas effizienter zu JOIN auf einem PRIMARY KEY als auf einem sekundären Schlüssel, der viel effizienter ist (aber immer noch möglich) als auf einer nicht indizierten Spalte (n).