phpmyadmin Kardinalität
- Ersteller bine
- Erstellt am
Albu
New member
Der Wert wird durch die Daten in den jeweiligen Tabellen bestimmt.
Ein Index ist ja normalerweise ein Teil einer Tabelle, meist der Teil nach dem die meisten Suchanfragen schauen. Dies soll verhindern, dass bei einer Anfrage in einer grossen Tabelle die komplette Tabelle mit ihren Feldern durchsucht werden muss. Statt dessen wird nur der wesentlich kleinere Index durchwühlt, was aufgrund diverser Optimierungsmechanismen erheblich schneller zum Ziel führt.
Die Kardinalität gibt nun an, wie groß / umfangreich der Index ist. Ein Index mit Kardinalität 1 ist ziemlich wertlos, denn alle Datensätze haben den gleichen Wert. Würde die DB bei ihrer Suche diesen Index einsetzen, dann müßten trotzdem alle Datensätze betrachtet werden.
Ein Index mit einer Kardinalität zwischen 1 und der Anzahl der Datensätze bildet für jeden Index Eintrag 1 bis n Datensätze der refernzierten Tabelle ab. Wird ein solcher Index eingesetzt, so werden also für jeden Treffer im Index 1 bis n Datensätze der Tabelle zurückgeliefert, die dann weiter betrachtet werden müssen. Ist die Kardinalität gleich der Anzahl der Datensätze der Tabelle, dann steht hinter jedem Eintrag im Index genau ein Eintrag in der Tabelle. Wenn der Index im Vergleich zur Tabelle klein/kurz ist, dann ist dieser Zugriff natürlich der schnellste, denn die DB muss nur den Index sortiert halten und kann mit rasender Geschwindigkeit darauf zugreifen.
Allerdings muss man auch aufpassen, wieviele Datensätze in der Tabelle gespeichert werden. Denn damit eine Suche schnell ausgeführt wird, sollte der Index komplett im Hauptspeicher liegen. Bei mehreren Millionen Datensätzen kann ein Index mehrere MB groß werden, wenn man dann noch mehrere solche Tabellen oder auch nur mehrere verschiedene Indizes für diese Tabelle hat, dann kann das plötzlich zu Performanceeinbußen führen.
Ein Index ist ja normalerweise ein Teil einer Tabelle, meist der Teil nach dem die meisten Suchanfragen schauen. Dies soll verhindern, dass bei einer Anfrage in einer grossen Tabelle die komplette Tabelle mit ihren Feldern durchsucht werden muss. Statt dessen wird nur der wesentlich kleinere Index durchwühlt, was aufgrund diverser Optimierungsmechanismen erheblich schneller zum Ziel führt.
Die Kardinalität gibt nun an, wie groß / umfangreich der Index ist. Ein Index mit Kardinalität 1 ist ziemlich wertlos, denn alle Datensätze haben den gleichen Wert. Würde die DB bei ihrer Suche diesen Index einsetzen, dann müßten trotzdem alle Datensätze betrachtet werden.
Ein Index mit einer Kardinalität zwischen 1 und der Anzahl der Datensätze bildet für jeden Index Eintrag 1 bis n Datensätze der refernzierten Tabelle ab. Wird ein solcher Index eingesetzt, so werden also für jeden Treffer im Index 1 bis n Datensätze der Tabelle zurückgeliefert, die dann weiter betrachtet werden müssen. Ist die Kardinalität gleich der Anzahl der Datensätze der Tabelle, dann steht hinter jedem Eintrag im Index genau ein Eintrag in der Tabelle. Wenn der Index im Vergleich zur Tabelle klein/kurz ist, dann ist dieser Zugriff natürlich der schnellste, denn die DB muss nur den Index sortiert halten und kann mit rasender Geschwindigkeit darauf zugreifen.
Allerdings muss man auch aufpassen, wieviele Datensätze in der Tabelle gespeichert werden. Denn damit eine Suche schnell ausgeführt wird, sollte der Index komplett im Hauptspeicher liegen. Bei mehreren Millionen Datensätzen kann ein Index mehrere MB groß werden, wenn man dann noch mehrere solche Tabellen oder auch nur mehrere verschiedene Indizes für diese Tabelle hat, dann kann das plötzlich zu Performanceeinbußen führen.
bine
Lounge-Member
ah so, ich glaub das hab ich kapiert.
Nun hab ich z.B. auch noch den Primärschlüssel mit auto_increment versehen, seh ich doch richtig, das, wenn ich z.B. kunde_id als Primärschlüssel anlege, diese dann autmatisch bei Neukundenanlage vergeben wird.
Und wenn ich nun noch kunde_nachname als Index nehme, dann ist dies das Feld welches die Kardinalität beeinflußt und außerdem als Sortierfeld der Datenbankeinträge dient!?
Also es werden dann nicht alle Felder der DB beim suchen gelesen sondern nur das Index-Feld!?
hm, kann man dann auch mehrere IndexFelder bestimmen? z.B. falls ein anderes Feld auch oft als Suchbegriff verwendet wird?
Nun hab ich z.B. auch noch den Primärschlüssel mit auto_increment versehen, seh ich doch richtig, das, wenn ich z.B. kunde_id als Primärschlüssel anlege, diese dann autmatisch bei Neukundenanlage vergeben wird.
Und wenn ich nun noch kunde_nachname als Index nehme, dann ist dies das Feld welches die Kardinalität beeinflußt und außerdem als Sortierfeld der Datenbankeinträge dient!?
Also es werden dann nicht alle Felder der DB beim suchen gelesen sondern nur das Index-Feld!?
hm, kann man dann auch mehrere IndexFelder bestimmen? z.B. falls ein anderes Feld auch oft als Suchbegriff verwendet wird?
Albu
New member
Jeder Index hat eine eigene Kardinalität. Ein Index der zugleich Primärschlüssel ist hat i.d.R. eine Kardinalität von n (= Anzahl Datensätze in Tabelle).
Wenn Du einen Index auf Nachname legst, dann heißt das, dass Abfragen nach dem Nachnamen schneller abgearbeitet werden können, weil nicht mehr die kompletten Adressdaten durchwühlt werden müssen, sondern nur noch dieser Index mit allen Nachnamen. Wenn Du dann auch noch alle Kunden mit Namen "Meier" haben willst, dann liefert Dir der Index sofort alle 15 Meiers aus Deiner Datenbank zurück, auf die Du dann sehr schnell zugreifen kannst.
Bei einer Suche nach Vorname und Nachname kommt es bei dieser Konstellation dagegen auf die Reihenfolge an. Wenn Du da nach Vorname zuerst suchst, dann durchwühlt er aufgrund des fehlenden Index "Vorname" die komplette Tabelle. Und würde dann unter Umständen erst den Index für Nachnamen verwenden (kann auch sein, dass gar keiner zum Einsatz kommt). Umgedreht würde er zunächst die Nachnamen einschränken und dann innerhalb der gefundenen Tupel den Vornamen in der Tabelle überprüfen.
Hast Du dagegen einen Index Nachname, Vorname würde die Suche nach einer Nachname + Vorname Kombination wesentlich schneller gehen. Suchst Du nach Vorname + Nachname, würde ein sogenannter TableScan durchgeführt, d.h. direkt in der Tabelle geschaut.
Auch bei der Sortierung hilft ein Index, weil ein Index sortiert gespeichert ist, allerdings auch nur solange, wie die Reihenfolge der Sortierkriterien mit der Reihenfolge in einem der Indizes übereinstimmt.
Man kann und sollte bei großen Tabellen mehrere Indizes anlegen, um für verschiedene Anwendungsfälle für schnellen Datenzugriff zu sorgen. Allerdings muß man dazu genau wissen, was die Anwendung braucht und wie sie die Daten abfragt. Andererseits muss der Anwendungsentwickler die vorhandenen Indizes möglichst optimal ausnutzen, um das letzte aus der Datenbank herauszuholen und die DB nicht zum Flaschenhals werden zu lassen.
Wenn Du einen Index auf Nachname legst, dann heißt das, dass Abfragen nach dem Nachnamen schneller abgearbeitet werden können, weil nicht mehr die kompletten Adressdaten durchwühlt werden müssen, sondern nur noch dieser Index mit allen Nachnamen. Wenn Du dann auch noch alle Kunden mit Namen "Meier" haben willst, dann liefert Dir der Index sofort alle 15 Meiers aus Deiner Datenbank zurück, auf die Du dann sehr schnell zugreifen kannst.
Bei einer Suche nach Vorname und Nachname kommt es bei dieser Konstellation dagegen auf die Reihenfolge an. Wenn Du da nach Vorname zuerst suchst, dann durchwühlt er aufgrund des fehlenden Index "Vorname" die komplette Tabelle. Und würde dann unter Umständen erst den Index für Nachnamen verwenden (kann auch sein, dass gar keiner zum Einsatz kommt). Umgedreht würde er zunächst die Nachnamen einschränken und dann innerhalb der gefundenen Tupel den Vornamen in der Tabelle überprüfen.
Hast Du dagegen einen Index Nachname, Vorname würde die Suche nach einer Nachname + Vorname Kombination wesentlich schneller gehen. Suchst Du nach Vorname + Nachname, würde ein sogenannter TableScan durchgeführt, d.h. direkt in der Tabelle geschaut.
Auch bei der Sortierung hilft ein Index, weil ein Index sortiert gespeichert ist, allerdings auch nur solange, wie die Reihenfolge der Sortierkriterien mit der Reihenfolge in einem der Indizes übereinstimmt.
Man kann und sollte bei großen Tabellen mehrere Indizes anlegen, um für verschiedene Anwendungsfälle für schnellen Datenzugriff zu sorgen. Allerdings muß man dazu genau wissen, was die Anwendung braucht und wie sie die Daten abfragt. Andererseits muss der Anwendungsentwickler die vorhandenen Indizes möglichst optimal ausnutzen, um das letzte aus der Datenbank herauszuholen und die DB nicht zum Flaschenhals werden zu lassen.
bine
Lounge-Member
oko doki, Hirarchie begriffen, danke Albu, ich weiß eigentlich grad gar nicht mehr warum ich das so schwer fand, denn eigentlich ist es nichts anderes als wenn ich z.B. eine Stammdatenverwaltung erstelle mit Serienbrieffunktionen und verschiedenen Sortierkriterien um daraus Werbung für Kunden zu versenden oder oder oder.