Warum hat die Kardinalität des Indexes in MySQL unverändert bleiben, wenn ich, fügen Sie einen neuen index?

Habe ich einen FULLTEXT-index auf eine meiner MySQL-Datenbank-Tabellen wie folgt:

ALTER TABLE members ADD FULLTEXT(about,fname,lname,job_title);

Das problem ist, dass mit phpmyadmin ich kann sehen, dass die Kardinalität von meiner neuen index ist nur 1. Bedeutet dies, dass der index nie verwendet werden?

Habe ich ein analyze table-Befehl, aber es nicht scheinen, nichts zu tun.

analyze table members

Den jeweiligen Typen der index-Felder sind varchar(100) varchar(100), text, varchar(200) und die engine ist MyISAM und die Tabelle hat über 30.000 Zeilen, die alle einzigartig. Meine MySQL-version ist 5.0.45.

Mache ich etwas falsch?

InformationsquelleAutor |
  1. 13

    Wenn man nur 1 Zeile in der Tabelle, die Kardinalität des index sollte 1 sein, natürlich. Es ist nur das zählen der Anzahl von eindeutigen Werten.

    Wenn Sie denken, dass der eine index-lookup-Tabelle, basierend auf Eimer (wie ein hash), dann ist die Kardinalität ist die Anzahl der buckets.

    Hier ist, wie es funktioniert: Wenn Sie erstellen einen index, über einen Satz von Spalten (a,b,c,d), dann geht die Datenbank über alle Zeilen in der Tabelle, der Blick auf die bestellte Vierlinge von diesen 4 Spalten für jede Zeile. Lassen Sie uns sagen, dass Ihre Tabelle sieht wie folgt aus:

    a  b  c  d  e   
-- -- -- -- --  
1  1  1  1  200 
1  1  1  1  300
1  2  1  1  200
1  3  1  1  200

    Also, was die Datenbank schaut, ist nur die 4 Spalten (a,b,c,d):

    a  b  c  d  
-- -- -- --
1  1  1  1 
1  2  1  1 
1  3  1  1

    Sehen, dass es nur 3 eindeutige Zeilen übrig? Diese werden unser Eimer, aber dazu kommen wir noch zurück. In der Realität, es gibt auch eine Datensatz-id, oder Zeilen-id für jede Zeile in der Tabelle. Also unsere ursprüngliche Tabelle sieht wie folgt aus:

    (row id) a  b  c  d  e   
-------- -- -- -- -- --  
00000001 1  1  1  1  200 
00000002 1  1  1  1  300
00000003 1  2  1  1  200
00000004 1  3  1  1  200

    So, wenn wir uns nur die 4 Spalten (a,b,c,d), wir sind wirklich auf der Suche auch auf die Zeilen-id:

    (row id) a  b  c  d 
-------- -- -- -- --
00000001 1  1  1  1
00000002 1  1  1  1
00000003 1  2  1  1
00000004 1  3  1  1

    Aber wir wollen lookup (a,b,c,d) und nicht durch eine Zeilen-id, also produzieren wir so etwas wie dieses:

    (a,b,c,d) (row id)
--------- --------
1,1,1,1   00000001
1,1,1,1   00000002
1,2,1,1   00000003
1,3,1,1   00000004

    Und schließlich gruppieren wir alle row-ids der Zeilen, die identicle (a,b,c,d) - Werte zusammen:

    (a,b,c,d) (row id)
--------- ---------------------
1,1,1,1   00000001 and 00000002
1,2,1,1   00000003
1,3,1,1   00000004

    Sehen, dass? Die Werte von (a,b,c,d) und (1,1,1,1) (1,2,1,1) und (1,3,1,1) zum Schlüssel für unsere lookup-Tabelle in den Zeilen der ursprünglichen Tabelle.

    Eigentlich nichts davon wirklich passiert, aber es sollte Ihnen eine gute Idee, wie man einen "naiven" (d.h. geradlinige) Implementierung eines index getan werden könnte.

    Aber unter dem Strich ist dies: Kardinalität nur misst, wie viele eindeutige Zeilen sind in einem index. Und in unserem Beispiel wurde die Anzahl der Schlüssel in unserem lookup-Tabelle, die war 3.

    Hoffe, das hilft!

    • Vielen Dank für die index-info. Sehr gut erklärt. Die Kardinalität von meinem index sollte mehr als 1 gegeben, es sind 30000 Zeilen, und fast jedes Mitglied hat einen anderen Namen?
    • Danke für die Erklärung über Indizes, es war sehr schön, aber deine Erklärung hat nicht beantwortet die oben gestellte Frage .
    • Du hast Recht, ich habe nicht explizit sagen, dass das abschließende Fazit: ich zeigten, dass nur 4 Zeilen fallen in 3 Eimer. Ich bin sicher, dass Sie erfinden könnte, eine weitere Zeile, die Hinzugefügt werden könnten, dass würde fallen in eine der bestehenden 3 Eimer des index. Verlassen würde die Anzahl der Gruppen unverändert, würde auch bedeuten, dass die Kardinalität des index war unverändert. Tut mir Leid, dass.
    • Schöne Erklärung. Aber 'Eigentlich nichts davon wirklich passiert' !? Also, was ist wirklich geschehen...? Ich fühle mich ein wenig verwirrt.
    • Naja, eine Datenbank-engine implementiert, die in einer naiven Weise können tatsächlich tun, alle die einzelnen Schritte. Aber ich erwarte, dass die meisten Implementierungen dieses anders - effizientere Nutzung der RAM-und disk-Ressourcen, um eine geringere Latenz.
    InformationsquelleAutor
  2. 11

    Kann ich nicht definitiv beantworten, warum MySQL nicht die Berechnung der Kardinalität, aber ich vermute es mal. Die MySQL-Handbuch Staaten:

    Kardinalität: Eine Schätzung der Anzahl eindeutiger Werte im index. Diese wird aktualisiert, durch ausführen von ANALYZE TABLE oder myisamchk -a. Kardinalität wird gezählt basierend auf den Statistiken gespeichert als ganze zahlen, so ist der Wert nicht unbedingt genau, auch für kleine Tische. Je höher die Kardinalität, desto größer ist die chance, dass MySQL verwendet den index, wenn dabei die Verknüpfungen.

    FULLTEXT-Indizes werden nur im MATCH ... GEGEN den (...) Abfragen, die Kräfte der index verwendet werden. Das MATCH ... GEGEN syntax funktioniert nicht, wenn es nicht einen FULLTEXT-index auf die Felder.

    Meine Vermutung ist, dass die Kardinalität nicht berechnet, weil es ist wirklich nicht notwendig.

    Beachten Sie, dass Suchanfragen gegen den index, obwohl die Kardinalität ist nicht festgelegt.

    Für die Aufzeichnung, ANALYSIEREN TABELLE foobar-Anweisung zu setzen scheint die Kardinalität korrekt.

    InformationsquelleAutor
Schreibe einen Kommentar