zur ersten frage: gehts nicht auch einfacher mit AUTOINCREMENT ?

@mike: Sagt mir nichts (Anfänger). Vielleicht kommt von den anderen noch was.

Muss ich eigentlich auch auf die Spalte einen Index setzen, nach der ich sortieren möchte? Ich dachte bisher, nur auf die Zeilen, die den Suchwert beinhalten. Aber wenn ich die Sortierung mit rein nehme, dauert die Abfrage ERHEBLICH länger. Das "Sortierfeld" hat bisher keinen Index.

[mysql]AUTOINCREMENT[/mysql]

[quote=olruebe01,08.04.2006, 11:07]Muss ich eigentlich auch auf die Spalte einen Index setzen, nach der ich sortieren möchte?[/quote]
Ein gemeinsamer Index über Suchfeld und Sortierfeld wäre vielleicht am sinnvollsten... bin mir dabei nicht ganz sicher, aber manche Datenbanken (MySQL...) optimieren maximal mit einem einzigen Index, daher könnte ein kokmbinierter Index es da vielleicht retten.

Du kannst je nach Datenbank auch auf Dein Sortierfeld einen CONSTRAINT machen, der die ganze Tabelle immer nach diesem Sortierfeld sortiert hält. Das verlangsamt das Schreiben auf die Tabelle etwas, aber dann brauchst Du später nicht mehr sortieren.

[quote=olruebe01,08.04.2006, 11:07]Muss ich eigentlich auch auf die Spalte einen Index setzen, nach der ich sortieren möchte?[/quote]
nicht, wenn die tabelle so klein ist, dass ein full-table-scan
schneller ist, als über einen index. wo die richtwerte für den
performanten einsatz von indizes einer mysql-datenbank liegen,
weiß ich leider nicht.

[quote=opi,09.04.2006, 10:23][quote=olruebe01,08.04.2006, 11:07]Muss ich eigentlich auch auf die Spalte einen Index setzen, nach der ich sortieren möchte?[/quote]
nicht, wenn die tabelle so klein ist, dass ein full-table-scan
schneller ist, als über einen index. wo die richtwerte für den
performanten einsatz von indizes einer mysql-datenbank liegen,
weiß ich leider nicht.[/quote]
Faustregel: "Ein Index ist erst dann sinnvoll, wenn die Anzahl der verschiedenartigen Werte in einer Spalte größer als 7 ist."

...so sagte mir ein Sybase-Optimierer vor äh - 7 - Jahren.

[quote=Relais,09.04.2006, 11:49]Faustregel: "Ein Index ist erst dann sinnvoll, wenn die Anzahl der verschiedenartigen Werte in einer Spalte größer als 7 ist."

...so sagte mir ein Sybase-Optimierer vor äh - 7 - Jahren.[/quote]
Unter Oracle gibt es beispielsweise Bitmap-Indizes, die sich für
Spalten eignen, auf denen es sehr wenig unterschiedliche Werte
gibt, wie zum Beispiel M(männlich) und W(weiblich) oder J(ja)
und N(nein).

Ein Bitmap-Index lohnt sich erst ab mehreren tausend Zeilen.
Ein normaler Index für eindeutige Werte kann schon ab 1.000
Zeilen die Abfragezeiten verkürzen, obwohl wir bei "uns" sogar erst
zwischen 10.000 und 100.000 Zeilen Indizes anlegen.\n\n

<!--EDIT|opi|1144578320-->

[quote=Relais,09.04.2006, 11:49]...so sagte mir ein Sybase-Optimierer vor äh - 7 - Jahren.[/quote]
dann gehörst du ja mittlerweile zum "alten eisen" ;-)\n\n

<!--EDIT|opi|1144578112-->

[quote=Relais,09.04.2006, 11:49]Faustregel: "Ein Index ist erst dann sinnvoll, wenn die Anzahl der verschiedenartigen Werte in einer Spalte größer als 7 ist."

...so sagte mir ein Sybase-Optimierer vor äh - 7 - Jahren.[/quote]
und es kommt auf die verteilung an. wenn du die werte a,b,c,d,e,f,g hast
und a-f nur selten vorkommen, g aber ganz häufig, bringt dir der index
bei der suche nach g nichts.

indizes sind eine wissenschaft für sich. du musst zum einen die verteilung
der werte berücksichtigen, du musst wissen, wie häufig nach was
abgefragt wird, und du musst wissen, wie häufig inserts im verhältnis
zu selects gemacht werden. wenn du häufig inserts hast, solltest du
mit indizes sparsam haushalten.\n\n

<!--EDIT|pq|1144597291-->

[quote=pq,09.04.2006, 17:34]wenn du häufig inserts hast, solltest du mit indizes sparsam haushalten.[/quote]
jo :)

Mann kann aber auch sowas notfalls noch mit Prozeduren hacken (falls die Datenbank das anbietet), um für Inserts nicht die Tabelle zu lähmen, dennoch schnell drauf zu suchen.