MySQL: INDEX - Verständnisfrage

[Tommi]

Hallo,

eine Frage, die ich trotz MySQL-Doku noch nicht ganz kapiert habe: Muss ich einen INDEX nur einmal beim Erstellen einer Tabelle anlegen und er bleibt dann automatisch aktuell? Oder muss ich, wenn ich etwas in die Datenbank eintrage, auch den INDEX aktualisieren?

Und noch was: ich habe mal einen INDEX auf eine Spalte angelegt, die mit WHERE abgefragt wird und mir die Microtime vor und nach der DB-Abfrage ausgeben lassen: mit dem Index ist es auch nicht schneller geworden (die datenbank hat ca. 3000 Einträge). Hab ich da was falsch gemacht?

Danke!
Tommi

[Axel Richter]

Hallo,

eine Frage, die ich trotz MySQL-Doku noch nicht ganz kapiert habe: Muss ich einen INDEX nur einmal beim Erstellen einer Tabelle anlegen und er bleibt dann automatisch aktuell?

Ja, jedesmal, wenn Daten eingefügt werden, werden die Indexdateien aktualisiert. Deshalb wird das Einfügen von Daten auch langsamer, je mehr Indexe es gibt. Dafür wird das Suchen in und Sortieren nach indizierten Spalten schneller.

Oder muss ich, wenn ich etwas in die Datenbank eintrage, auch den INDEX aktualisieren?

Nein, das mach das DBMS von selbst.

Und noch was: ich habe mal einen INDEX auf eine Spalte angelegt, die mit WHERE abgefragt wird und mir die Microtime vor und nach der DB-Abfrage ausgeben lassen: mit dem Index ist es auch nicht schneller geworden (die datenbank hat ca. 3000 Einträge). Hab ich da was falsch gemacht?

Die erste Frage wäre, wird der Index überhaupt genutzt? Bei ... WHERE name LIKE "%a%" kann er nämlich nicht genutzt werden. Bei ... WHERE name LIKE "a%" dagegen wird er genutzt.

Ansonsten kommt es darauf an, was Du da überhaupt misst. Meist dauern die Abfragen selbst nur einige zehntel Sekunden. Die Hauptzeit verbraucht das PHP-Script mit dem Erstellen des Arrays für die Ergebnismenge. Diese Zeit misst Du mit, weil beides in einer Anweisung erfolgt.

viele Grüße

Axel

[Tommi]

Hallo Axel,

danke für Deine Antwort!

Die erste Frage wäre, wird der Index überhaupt genutzt? Bei ... WHERE name LIKE "%a%" kann er nämlich nicht genutzt werden. Bei ... WHERE name LIKE "a%" dagegen wird er genutzt.

In meinem Test war das einfach nur WHERE name = "...".

Gruß
Tommi

[Andreas-Lindig]

Muss ich einen INDEX nur einmal beim Erstellen einer Tabelle anlegen und er bleibt dann automatisch aktuell? Oder muss ich, wenn ich etwas in die Datenbank eintrage, auch den INDEX aktualisieren?

nö, das geht automatisch

Und noch was: ich habe mal einen INDEX auf eine Spalte angelegt, die mit WHERE abgefragt wird und mir die Microtime vor und nach der DB-Abfrage ausgeben lassen: mit dem Index ist es auch nicht schneller geworden (die datenbank hat ca. 3000 Einträge). Hab ich da was falsch gemacht?

vielleicht mit ungleich abgefragt oder die Spalte mit einer Funktion bearbeitet oder mit LIKE '%...%' abgefragt oder die Einträge sind so ähnlich, daß ein Index nichts nützt...

Gruß, Andreas

[Tommi]

Hallo Andreas,

... oder die Einträge sind so ähnlich, daß ein Index nichts nützt...

Aha, ab welcher Ähnlichkeit nützt denn ein INDEX nichts? Wie ist es denn  bei einer INTEGER-Spalte, nützt da ein INDEX?

Danke & Gruß
Tommi

[Tom]

Hello,

Aha, ab welcher Ähnlichkeit nützt denn ein INDEX nichts? Wie ist es denn  bei einer INTEGER-Spalte, nützt da ein INDEX?

Ein Index nützt dann, wenn der Hauptspeicher knapp wird und die Datenmenge steigt. Dann werden nämlich die Zugriffe auf den Datenträger lahm und da ist es dann sinnvoll, wenn man nur wenige Zugriffe benötigt und nicht erst deie ganze Tabelle durchsuchen muss.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tommi]

Hallo Tom,

Ein Index nützt dann, wenn der Hauptspeicher knapp wird und die Datenmenge steigt. Dann werden nämlich die Zugriffe auf den Datenträger lahm und da ist es dann sinnvoll, wenn man nur wenige Zugriffe benötigt und nicht erst deie ganze Tabelle durchsuchen muss.

OK und im Prinzip bei allen Spaltentypen, oder?

Gruß
Tommi

[Tom]

Hello,

Ein Index nützt dann, wenn der Hauptspeicher knapp wird und die Datenmenge steigt. Dann werden nämlich die Zugriffe auf den Datenträger lahm und da ist es dann sinnvoll, wenn man nur wenige Zugriffe benötigt und nicht erst deie ganze Tabelle durchsuchen muss.

OK und im Prinzip bei allen Spaltentypen, oder?

Nein, nicht bei allen. Bei Spalten mit erheblich eingeschränktem Wertevorrat (Logical, enum) lohnt sich das selten. Es gibt auch Datenbanksysteme, die deshalb den Index dafür kategorisch ablehnen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tommi]

Hallo Tom,

Nein, nicht bei allen. Bei Spalten mit erheblich eingeschränktem Wertevorrat (Logical, enum) lohnt sich das selten. Es gibt auch Datenbanksysteme, die deshalb den Index dafür kategorisch ablehnen.

Wie wäre es für die Spalte "Typ" (INTEGER), da ist ja eigentlich auch kaum Information drin (die zahlen können aber auch groß werden), es werden aber solche Abfragen gemacht: SELRCT irgendwas FROM Tabelle WHERE Typ = 3.

+----+-----+
| ID | Typ |
+----+-----+
|  1 |   1 |
+----+-----+
|  2 |   1 |
+----+-----+
|  3 |   2 |
+----+-----+
|  4 |   1 |
+----+-----+
|  5 |   3 |
+----+-----+
|  6 |   2 |
+----+-----+

Gruß
Tommi

[Andreas-Lindig]

+----+-----+
| ID | Typ |
+----+-----+
|  1 |   1 |
+----+-----+
|  2 |   1 |
+----+-----+
|  3 |   2 |
+----+-----+
|  4 |   1 |
+----+-----+
|  5 |   3 |
+----+-----+
|  6 |   2 |
+----+-----+

sowas meinte ich mit ähnlich: 1, 1, 2, 1, 3, 2... viele Wiederholungen. Da ist ein Index wohl ziemlich nutzlos und verlangsamt eher nur die Einträge.

Gruß, Andreas

[Tommi]

Hallo,

sowas meinte ich mit ähnlich: 1, 1, 2, 1, 3, 2... viele Wiederholungen. Da ist ein Index wohl ziemlich nutzlos und verlangsamt eher nur die Einträge.

OK, danke. Schon wieder was gelernt! :-)

Gruß
Tommi

[Axel Richter]

Hallo,

sowas meinte ich mit ähnlich: 1, 1, 2, 1, 3, 2... viele Wiederholungen. Da ist ein Index wohl ziemlich nutzlos und verlangsamt eher nur die Einträge.

Das kann ich so nicht unwidersprochen stehen lassen. Der Index würde vorsortieren und damit ein
... WHERE Typ = 2
oder
... OREDR BY Typ
beschleunigen.

Lohnen würde sich das _immer_ bei einer größeren Anzahl von Datensätzen. Wie häufig Typ 1, 2 oder 3 vorkommt, spielt _keine_ Rolle. Ohne Index muss die _gesamte_ Datensatzmenge durchsucht werden. Mit Index _nur_ die Datensatzmenge mit dem geforderten Wert für Typ im Index. Ohne Index muss eine Sort-Methode über die gesamte Tabelle laufen. Mit Index wird einfach die sortierte Index-Tabelle verwendet.

viele Grüße

Axel

[Tom]

Hello,

sowas meinte ich mit ähnlich: 1, 1, 2, 1, 3, 2... viele Wiederholungen. Da ist ein Index wohl ziemlich nutzlos und verlangsamt eher nur die Einträge.
Das kann ich so nicht unwidersprochen stehen lassen. Der Index würde vorsortieren und damit ein
... WHERE Typ = 2
oder
... OREDR BY Typ
beschleunigen.

So?
Wie werden denn Referenzen aus Indexseiten gesucht?
Woher weiß denn die Find-Funktion des Index, ob der Index balanciert ist, oder auf fast allen Seiten nur 1en hat?

Und hinter welcher 1 sich dann die anderen passenden Wete verstecken, woher weiß sie das?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Axel Richter]

Hallo,

Wie werden denn Referenzen aus Indexseiten gesucht?

Es war bisher nur von _einer_ Tabelle die Rede. Oder welche "Referenzen" meinst Du?

Woher weiß denn die Find-Funktion des Index, ob der Index balanciert ist, oder auf fast allen Seiten nur 1en hat?

Was ist die Find-Funktion eines Index? Warum ist balanciert und "auf fast allen Seiten nur 1en haben" für Dich offensichtlich ein Gegensatz? Was hat es überhaupt miteinander zu tun?

Und hinter welcher 1 sich dann die anderen passenden Wete verstecken, woher weiß sie das?

Den genauen Ablauf des Index-optimierten Ausführes von WHERE, ORDER BY, SUM() usw. kann ich nicht beschreiben. Ich weiß aber, das Indexe diese Vorgänge optimieren. Hier http://www.linux-magazin.de/Artikel/ausgabe/2001/11/oracle/oracle.html z.B. beschrieben unter der Überschrift "Mit Zeigefinger...". Und ch weiß, dass auch MySQL B*-Tree-Indexe benutzt.

In etwa arbeitet ein Spalten-Index so:
In einem separaten File werden Verweise auf alle Datensätz einer Tabelle nach der indizierten Spalte vorsortiert gespeichert. Wird diese Spalte, z.B. in WHERE, angefordert, dann wird nicht die gesamte Tabelle nach dem geforderten Wert durchsucht und die gefundenen Datensätze gesammelt, die über die gesamte Tabelle versteut liegen können, sondern in der vorsortierten Index-Tabelle wird der erste übereinstimmende Datensatz gesucht, was wegen der Sortierung schon schneller geht. Die weiteren übereinstimmenden Datensätze müssen nun, wegen der Sortierung, unmittelbar folgen.

Natürlich lohnt es sich nicht, Spalten zu idexieren, die ausschließlich _einen_ Wert enthalten können. Aber sonst dürften Indexe _immer_ etwas bringen. Stell Dir eine Tabelle mit 100.000 Datensätzen vor, deren Typ-Spalte 70.000 Mal 1 und 30.000 Mal 2 enthält. Du bist wirklich der Meinung, dass ein Index auf Typ, welcher dafür sorgt, dass erst die 70.000 und dann die 30.000 Datensätze vorsortiert werden, keinen Vorteil gegenüber einem full-table-scan in der unsortierten Tabelle bringt?

viele Grüße

Axel

[Tom]

Hello,

Wie werden denn Referenzen aus Indexseiten gesucht?
Es war bisher nur von _einer_ Tabelle die Rede. Oder welche "Referenzen" meinst Du?

Mit _einer_ Tabelle kann ich aber nicht Daten UND Index darstellen.
Dazu bwenötige ich eine Datentabelle und eine Indextabelle. Wenn ich mir MySQL "innen drin" ansehe, sind die sogar nochmals in viele Blattseiten unterteilt, beide!

In der Index-Tabelle finde ich in einer geordneten Struktur den Schlüsselwert und diesem Zugeordnet eine referenz in die ungeordnete Datentablle, i.d.R. auf den Beginn des Datensatzes, in dem der Schlüssel in der Satzstruktur eingeordent zu finden ist.

Woher weiß denn die Find-Funktion des Index, ob der Index balanciert ist, oder auf fast allen Seiten nur 1en hat?
Was ist die Find-Funktion eines Index? Warum ist balanciert und "auf fast allen Seiten nur 1en haben" für Dich offensichtlich ein Gegensatz? Was hat es überhaupt miteinander zu tun?

Ein Index, der nur gleiche Schlüsselwerte enthält, kann nicht balanciert sein. Es gitnja gar kein Balance-Kriterium mehr.

Es lohnt sich wirklich, mal alles mit Flatfiles selber aufzubauen, damit man die Mühe nachvollziehen kann, die in einem DBMS steckt.

Dabei darf man sich auch nicht gegenüber  "neuen" oder anderen Lösungswegen verschließen, auch wenn man dann in den Augen der "Profis" als Laie oder Spinner gilt. Viele dieser "Profis" sind nur verschulte Nachplapperer.

Allerdings glaube ich nicht daran, dass man in der Datenteechnik noch wirklich Neues entwickeln kann. Schließlich sind die Informationstechnischen Grundlagen bereits in einer Zeit vor über 150 Jahren (wenn man Heinz Nixdorf Glauben schenken soll sogar 4000 v. Chr.) entwickelt worden.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Lohnen würde sich das _immer_ bei einer größeren Anzahl von Datensätzen. Wie häufig Typ 1, 2 oder 3 vorkommt, spielt _keine_ Rolle.

Natürlich lohnt es sich nicht, Spalten zu idexieren, die ausschließlich _einen_ Wert enthalten können. Aber sonst dürften Indexe _immer_ etwas bringen.

nun bist du ja schon von "spielt gar keine rolle" zu "einen_wert" übergegangen. jetzt musst du noch verstehen, dass es nicht nur um einen oder zwei unterschiedliche werte geht, die einen index langsamer machen können.

Du bist wirklich der Meinung, dass ein Index auf Typ, welcher dafür sorgt, dass erst die 70.000 und dann die 30.000 Datensätze vorsortiert werden, keinen Vorteil gegenüber einem full-table-scan in der unsortierten Tabelle bringt?

ganz genau, so ist es.

Ilja

[Tom]

Hello,

Du bist wirklich der Meinung, dass ein Index auf Typ, welcher dafür sorgt, dass erst die 70.000 und dann die 30.000 Datensätze vorsortiert werden, keinen Vorteil gegenüber einem full-table-scan in der unsortierten Tabelle bringt?

ganz genau, so ist es.

Wobei man vielleicht sagen muss, dass der wesentliche Nachteil hier in der Pflege des Index liegt. Idizes basieren ja ausschließlich auf ordinalen (oder "ordinalisierten") Werten.

Welche Zahl ist Größe als 1?
 Wann erwartest Du die 2 in eine sortierten Liste?

Ich erwarte die 2 direkt ein Element hinter der 1.

Aber Käse. Da steht jetzt 70.000 mal die 1
 Muss ich also zur Pfelge des Index 70.000 mal vergleichen.

Was passiert nun beim Suchen?

Ich treffe beim ersten Peek eine 1. Aber die zweite Filter-Bedingung (zweite Spalte) stimmt nicht. Muss ich den Index jetzt nach "links" oder nach "rechts" weitersuchen? Wenn ich psch habe, muss ich sowohl den linken, also auch den rechten Flügel des durch mein peek() geteilten 1-Bereiches durchsuchen, also auch 70.000 mal.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Wobei man vielleicht sagen muss, dass der wesentliche Nachteil hier in der Pflege des Index liegt.

nein, das würde ich nicht meinen. ich würde bei (70.000/30.000) unabhängig von der pflege keinen b-baum index verwenden, weil er mir nur nachteile und keine vorteile bringt. sollte das dbms diesen index benutzen, dann ist das einfach mal langsamer. ein bitmap index ist da was anderes, aber nicht jedes dbms kennt diesen.

Ilja

[Tom]

Hello,

Wobei man vielleicht sagen muss, dass der wesentliche Nachteil hier in der Pflege des Index liegt.

nein, das würde ich nicht meinen. ich würde bei (70.000/30.000) unabhängig von der pflege keinen b-baum index verwenden, weil er mir nur nachteile und keine vorteile bringt. sollte das dbms diesen index benutzen, dann ist das einfach mal langsamer. ein bitmap index ist da was anderes, aber nicht jedes dbms kennt diesen.

Da gibts eine ganz nette ppt-Präsentation... http://www.informatik.hu-berlin.de/Forschung_Lehre/wbi/teaching/sose04/dwh/uebung4/indexierung.ppt

Aber ich stimme Dir noch nicht ganz zu. Da musst Du bitte nochmal etwas Nachhilfe leisten.

Die Art des Index auf ein "normales" Textfeld legt doch i.d.R. der Programmierer beim Design der Tabelle fest, und nicht das DBMS während der Eingabe von Daten. Wenn sich nun während der Befüllung der Spalte erst herausstellt, dass der üblich Index hier ungeeignet ist, gibt es das DBMS, die das automatisch erkennen und dann automatisch ein Reindex auf den anderen Typ durchführen?

Da ein Bitmap-Index bis zu einer bestimmten Anzahl von möglichen Werten ja sehr schlank ist, könnte man ihn ja eine zeitlang einfach parallel mitführen und gelegentlich einen Seektest durchführen. Der Index, der gewinnt, bleibt für die Suche aktiv. Das erspart einem aber trotzdem nicht den Aufwand bei der Pflege. Die Pflege des inaktiven Index könnte man aber auf weniger belastete Zeiten verschieben.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Aber ich stimme Dir noch nicht ganz zu. Da musst Du bitte nochmal etwas Nachhilfe leisten.

es wäre ja auch schlimm, wenn man in allem immer übereinstimmt. es gibt halt einfach zu bestimmten dingen verschiedene ansichten. das könnte man auch einfach so stehen lassen.

Die Art des Index auf ein "normales" Textfeld legt doch i.d.R. der Programmierer beim Design der Tabelle fest, und nicht das DBMS während der Eingabe von Daten.

jein, eher nicht, wobei jeder da seine vorgehensweise hat. das ist ja mal ein nichtssagender satz ;-)

aber wenn ich die ersten drei normaliserungen durchgehe, dann steht da erst einmal nichts von index. so wie in der präsentation hat ein index andere kriterien, nach denen beurteilt wird. viel wichtiger als das design der daten (tabellen) ist der inhalt und vielmehr noch die art, wie ich die daten abfrage, sprich kommt eine spalte in einer where bedingung vor, benutzt sie eine funktion, ist die spalte ein join kriterium, etc. das sind dann eher die dinge, wonach man einen index anlegt. sicherlich spielt das design auch eine grosse rolle, deswegen denormalisiert man eventuell auch wieder. aber ich würde keinen index nur aufgrund des designs setzen.

Wenn sich nun während der Befüllung der Spalte erst herausstellt, dass der üblich Index hier ungeeignet ist, gibt es das DBMS, die das automatisch erkennen und dann automatisch ein Reindex auf den anderen Typ durchführen?

dynamik in datenbanken ist ja nun gerade das kriterium was für eine datenbank spricht. es ist ein ganz normaler vorgang, dass ein design und auch ein index nicht für die ewigkeit geschaffen ist. dbms versuchen das zu "händeln", sprich dafür ist der optimierer zuständig. wie genau das passiert, ist recht kompliziert und funktioniert auch nicht immer. deswegen gibt es unter oracle auch sogenannte hints, die der "intelligenz" des dbms einhalt gebieten, wenn er was tut, was sich nicht als ganz nützlich herausstellt. bei oracle zum beispiel arbeitet der optimierer auf zwei unterschiedliche arten, rule based und cost based. bei der ersten art geht er stur nach ganz bestimmen regeln vor, sprich gibt es da einen index, etc. der cost based ist komplexer und versucht verschiedene wege zu bewerten, wobei er hier auf bestimmte informationen zurückgreift, quasi eine art erfahrungs und bewertungsliste.

Da ein Bitmap-Index bis zu einer bestimmten Anzahl von möglichen Werten ja sehr schlank ist, könnte man ihn ja eine zeitlang einfach parallel mitführen und gelegentlich einen Seektest durchführen. Der Index, der gewinnt, bleibt für die Suche aktiv. Das erspart einem aber trotzdem nicht den Aufwand bei der Pflege. Die Pflege des inaktiven Index könnte man aber auf weniger belastete Zeiten verschieben.

bei einer kardinalität von 70.000/30.000 braucht man keinen test b-tree gegen bitmap, vielleicht nur, um sich den unterscheid einmal vor augen zu führen. der sollte nämlich sehr gross sein. aber liegt die sache nicht so klar auf der hand, kann man sicherlich verschiedene möglichkeiten durchspielen, wobei ein index nicht die einzige möglichkeit ist. und genau das wird auch in der praxis gemacht, "set timing on" und sehen, wielange mit einer bestimmten veränderung bestimmte vorgänge brauchen.

Ilja

[Tom]

Hello und danke Ilja,

sollte ich jemals wieder "Spielgeld" übrig haben, werd ich mal intensiv über Oracle informieren lassen. Aber so ein Runum-glücklich-Packet mit mund für Oracle kostet schon mal seine 50.000 Euro.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

sollte ich jemals wieder "Spielgeld" übrig haben, werd ich mal intensiv über Oracle informieren lassen. Aber so ein Runum-glücklich-Packet mit mund für Oracle kostet schon mal seine 50.000 Euro.

nah, es gibt immer einen weg. zufälligerweise genau heute habe ich doch post bekommen, mit drei kleinen cd's oracle 10g und das alles kostenlos ganz offiziell und legal. einfach mal die oracle seite besuchen gehen und umschauen. nur mein windows ME spielt da nicht mehr mit. muss ich mich wohl unter schmerzen davon trennen....

Ilja

[Ilja]

yo,

Lohnen würde sich das _immer_ bei einer größeren Anzahl von Datensätzen. Wie häufig Typ 1, 2 oder 3 vorkommt, spielt _keine_ Rolle. Ohne Index muss die _gesamte_ Datensatzmenge durchsucht werden. Mit Index _nur_ die Datensatzmenge mit dem geforderten Wert für Typ im Index.

ich will da tom recht geben. es spielt sehr wohl eine sehr grosse rolle, wie gross die kardinalität der entsprechenden spalte ist. die aussage, dass ein fullscan ohne index genauso lange dauert wie mit index ist falsch. du musst dir vor augen halten, dass ein datensatz über einen index zuzugreifen auch einen längeren weg zur folge hat.

tom hat sicherlich vergessen zu erwähnen, dass einige gut dbms für spalten mit geringer kardinalität einen besondern bitmap index bereitstellen, der dann alles noch schneller macht, so zum beispiel oracle.

Ilja

[Axel Richter]

Hallo,

ich will da tom recht geben. es spielt sehr wohl eine sehr grosse rolle, wie gross die kardinalität der entsprechenden spalte ist.

Die Kardinalität hat damit gar nichts zu tun.
http://de.wikipedia.org/wiki/Kardinalität_(Datenbanken)

die aussage, dass ein fullscan ohne index genauso lange dauert wie mit index ist falsch.

Das habe ich auch nicht behauptet.

du musst dir vor augen halten, dass ein datensatz über einen index zuzugreifen auch einen längeren weg zur folge hat.

Ja, mit Index muss aber gar kein Fullscan gemacht werden.

viele Grüße

Axel

[Tom]

Hello,

du musst dir vor augen halten, dass ein datensatz über einen index zuzugreifen auch einen längeren weg zur folge hat.
Ja, mit Index muss aber gar kein Fullscan gemacht werden.

Dafür muss das Index-File mit Fullscan belegt werden, wenn keine ausreichende Tiefe vorhanden ist.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tommi]

Hallo,

hm, also allmählich bin ich "so schlau als wie zuvor" ;-)

Ich habe jetzt einfach mal folgendes Probiert:

ich habe eine Tabelle mit zwei Spalten, id (INT, auto_increment) und x (INT) angelegt.
Nun habe ich 10000 Zeilen mit Werten für x zwischen 1 und 100 eingetragen.
Dann habe ich die Tabelle mit Inhalt kopiert und für die Kopie einen Index für "x" erstellt.

Mit diesem Skript habe ich dann die Geschwindigkeit verglichen:

<?php
$mit_index_schneller = 0;
for($x=0; $x<1000; $x++)
 {
  $start = microtime(true);
  $result = mysql_query("SELECT * FROM table_no_index WHERE x=17 OR x=53 OR x=74",$c);
  $ende = microtime(true);
  $dif = $ende-$start;

$start2 = microtime(true);
  $result2 = mysql_query("SELECT * FROM table_index WHERE x=17 OR x=53 OR x=74",$c);
  $ende2 = microtime(true);
  $dif2 = $ende2-$start2;

if ($dif2 < $dif) $mit_index_schneller++;
 }

echo 'Von '.$x.' Durchläufen war die Tabelle mit Index '.$mit_index_schneller.' mal schneller.';
?>

Ergebnis: "Von 1000 Durchläufen war die Tabelle mit Index 993 mal schneller."

Scheint also halbwegs eindeutig zu sein!

Gruß
Tommi

[Tom]

Hello,

ich habe eine Tabelle mit zwei Spalten, id (INT, auto_increment) und x (INT) angelegt.
Nun habe ich 10000 Zeilen mit Werten für x zwischen 1 und 100 eingetragen.

Eine Spreizung von 1 bis 100 bringt ja auch in einem binären Baum schon 7 Ebenen. Und andere Indexstrukturen sind noch schneller, als binäre Bäume.

Wenn ein Index generell unsinnig wäre, würde ihn kein DBMS benutzen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ilja]

yo,

Die Kardinalität hat damit gar nichts zu tun.

hat sie sehr wohl. nehmen wir zum beispiel eine kundentabelle mit der spalte ort. wir haben cirka 5000 kunden alle wohnen nun im Ort Berlin. ein index bringt hier rein gar nichts, wenn ich mir alle kunden aus berlin anzeigen lassen will. im gegenteil, wenn der optimierer (unter oracle zum besipiel unter rule based) den index sieht und nun über diesen alle aus berlin ermitteln will. das würde wesentlich länger dauern die 5000 datensätze über den index als ohne index auszugeben.

Ja, mit Index muss aber gar kein Fullscan gemacht werden.

dies trifft aber nur zu, wenn du sehr selektiv bist und dabei spielt die kardinalität wieder eine rolle. ein fullscan kann bei bestimmten abfragen sehr wohl besser sein, auch wenn es einen index gibt. eine faustregel besagt, wenn 10% der daten in die ergebnismenge kommen, dann ist ein b-tree index schneller.

Ilja