[MySQL] Index auf varchar(32) zufallscode

2

27o8

abgemeldet
2 Mai 2006
9.028
933
Moin,
lohnt es sich in einer Tabelle in der es circa 1000 Einträge gibt welche alle einen eindeutigen Code haben welcher 32stellen Lang ist und per Zufall erzeugt wird einen Index auf dieses Feld zu setzen wenn es oft Abfragen gibt wo so eine Spalte geupdatet wird?

Mir wurde mal gesagt das es sich nicht(!) lohnt was ich irgendwie nicht verstehe ;)

Gruß
Gremlin
 
neija es hängt ja auch davon ab ob Abfragen darauf kommen, ansonsten muss MySQL jedesmal alle 1000 Zeilen aus der DB laden und checken (full-table-scan) also mit dem lohnt sich nicht wäre ich da vorsichtig
 
Das kommt ganz auf die Art und Häufigkeit der Nutzung an.

In der Tat ist es aufwändiger, Updates zu verarbeiten, weil bei jeder Wertänderung der Index aktualisiert werden muß.

Finden also mehr Updates / Deletes als Selects statt, dann sollte man keinen Index verwenden.
Andererseits wird dann bei jedem Select ein Scan der Spalte notwendig, das ist ein vielfaches an Aufwand gegenüber der Nutzung eines Index.

Wichtig dabei ist aber auch, daß der Select so formuliert wird, dass ein Index genutzt werden kann. Dazu sind bestimmte Voraussetzungen notwendig.

Man kann dies übrigens unter PHPMyAdmin ganz gut nachvollziehen, wie effizient die Datenbank insgesamt arbeitet. Unter anderem sieht man dort die Anzahl der "Scans", also das durchlesen aller Zeilen der Datenbank anstelle der Index-Verwendung.

Ich hoffe, das hat dir ein wenig geholfen. Leider gibt es keine generelle Regel, sondern nur die Beschreibung der Voraussetzungen.

Liebe Grüsse


Gremlin schrieb:
Moin,
lohnt es sich in einer Tabelle in der es circa 1000 Einträge gibt welche alle einen eindeutigen Code haben welcher 32stellen Lang ist und per Zufall erzeugt wird einen Index auf dieses Feld zu setzen wenn es oft Abfragen gibt wo so eine Spalte geupdatet wird?

Mir wurde mal gesagt das es sich nicht(!) lohnt was ich irgendwie nicht verstehe ;)

Gruß
Gremlin
Zum Vergrößern anklicken....
 
Danke für eure Antworten? Also die Tabelle ist eigentlich die die am meisten abgefragt wird ums mal zu sagen was es ist: Das VMS ;) genauer:

vms_gebuchte_werbung

dort hat jede Werbekampagne eine tan (dieser 32 stellige Code) und es wird halt bei jedem Klick z.B. die Url Abgefragt, nach einem Klick die restmenge um 1 subtrahiert. Ausserdem wird halt geschaut ob die Kampagne im Reload ist mit einem Join nach der Reloadtabelle. Ändern tut sich der Code einer Kampagne eigentlich nie ;) es kommen halt nur ab und zu neue Kampagnen dabei.

Bei jedem Klick ist es also derzeit:
- 2 SELECT
- 1 UPDATE

Gruß
Gremlin
 
*gg*
da hat jemand aber was komplett falsch verstanden und dir mist erzählt^^

das einzige was performance-probleme macht, ist, wenn du zb die tan dauernd ändern würdest, auf welcher der index liegt.

So gibt es keinen Grund keinen index zu nutzen.
 
Ohne nun genauer einen Blick darauf geworfen zu haben würde ich hier einen Index vorziehen.

Aber die Kriterien kennst du ja nun. Zudem scheint es nicht wirklich performancekritisch zu sein. Einen Unterschied würdest du nur merken, wenn die Tabelle wirklich jede Sekunde im Zugriff wäre.

Aber das Thema ist durchaus wichtig. Vielleicht beschäftigst du dich ja mal weiter mit den Themen.

In diesem Zusammenhang noch ein Hinweis zum Testen von Statements, z.B. ob ein Index benutzt wird: das sogenannte Explain plan.
Damit gibst du der Datenbank nach Anweisung von Explain select... die Möglichkeit, sogenannte Zugriffspfade auf die Daten anzuzeigen. Unter anderen steht eben drin, ob einer der vorhandenen Indizes genutzt werden.

Kann hilfreich sein bei der Entwicklung, wenn man weiß, wie die Datenbank vorgeht.


Gremlin schrieb:
Danke für eure Antworten? Also die Tabelle ist eigentlich die die am meisten abgefragt wird ums mal zu sagen was es ist: Das VMS ;) genauer:

vms_gebuchte_werbung

dort hat jede Werbekampagne eine tan (dieser 32 stellige Code) und es wird halt bei jedem Klick z.B. die Url Abgefragt, nach einem Klick die restmenge um 1 subtrahiert. Ausserdem wird halt geschaut ob die Kampagne im Reload ist mit einem Join nach der Reloadtabelle. Ändern tut sich der Code einer Kampagne eigentlich nie ;) es kommen halt nur ab und zu neue Kampagnen dabei.

Bei jedem Klick ist es also derzeit:
- 2 SELECT
- 1 UPDATE

Gruß
Gremlin
Zum Vergrößern anklicken....
 
Aber das Thema ist durchaus wichtig. Vielleicht beschäftigst du dich ja mal weiter mit den Themen.
Zum Vergrößern anklicken....
Ja Optimierung der Datenbank (und sql / mysql allgemein) ist im moment eigentlich das womit ich mich hauptsächlich beschäftige.

Das EXPLAIN ist wirklich sehr hilfreich hatte da früher schonmal von gehört aber nie wirklich genutzt. Habe es nun allerdings mal genutzt und schaut wirklich sehr hilfreich aus :)

Danke!

Gruß
Gremlin
 
Immer 32 Stellen... varchar? Da gibts auch ein anderes Feld für ;) Aber ok das ist eher Haarspalterei.

Und zum Thema Index. Die Felder die man regelmässig für den Zugriff auf ein Datensatz nutzt sind meistens richtig aufgehoben als Index. Ausnahmen bestätigen natürlich die Regel, aber im großen und ganzen kann man da gar nicht soviel falsch machen. (vorrausgesetzt man hat ein ordentliches Tabellen Design)
Ein was sollte man dabei aber noch wissen, Mysql nutz maximal einen Index pro Tabelle in einer Abfrage.
 
In seltenen Fällen sind es auch mal 16 Stellen ;) wenns immer 32 wären hätte ich char genutzt ^^ aber so lohnt das ja nicht :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben