mysql und der index

[easteregg]

heyho

ich bin grad dabei meine anwendungen zu optimieren und hab daher das logging von indexlosen queries aktiviert.

nun taucht zb folgender immer wieder auf:

DELETE FROM sessions WHERE timeout < 1280934301

und das wowohl auf timeout nen index drauf ist.
liegt das an dem kleiner als ?
und wenn ja, wie kann man sowas optimieren?

 

[metax.]

Hallo,
du solltest am besten in jeder Tabelle einen Primärschlüssel haben - und wenn es nur eine forlaufende ID ist. Das macht so Aktionen schonmal schneller.
Ansonsten kannst du zusätzlich einen Schlüssel auf das timeout-Feld machen, aber das hast du ja offenbar schon.
Kannst du mal deine Tabellen-Defintion posten (inklusive Indizes und Feldtypen)?

mfg, metax.

 

[easteregg]

die standard sachen sind sauber gesetzt, wie ich se brauch:

CREATE TABLE sessions (
  id int(10) unsigned NOT NULL auto_increment,
  user_id int(10) NOT NULL default '0',
  logintime int(10) NOT NULL default '0',
  ip varchar(15) NOT NULL,
  hostname varchar(200) NOT NULL,
  lastsite varchar(50) default NULL,
  useragent varchar(500) default NULL,
  session_id varchar(32) NOT NULL,
  timeout int(10) NOT NULL,
  lastaction int(10) NOT NULL,
  vars varchar(1000) default NULL,
  PRIMARY KEY  (id),
  KEY timeout (timeout),
  KEY session_id (session_id)
) ENGINE=MEMORY  DEFAULT CHARSET=utf8;

 

[metax.]

Hm, ich hab da in der MySQL-Doku was gefunden (speziell für die MEMORY-Engine):

Die Speicher-Engine MEMORY implementiert sowohl HASH- als auch BTREE-Indizes. Mit einer USING-Klausel können Sie angeben, welchen von beiden Sie wünschen:

CREATE TABLE lookup
    (id INT, INDEX USING HASH (id))
    ENGINE = MEMORY;
CREATE TABLE lookup
    (id INT, INDEX USING BTREE (id))
    ENGINE = MEMORY;

Die allgemeinen Merkmale von B-Baum- und Hash-Indizes werden in Abschnitt 7.4.5, „Wie MySQL Indizes benutzt“ beschrieben.

Wenn Sie einen Hash-Index auf einer MEMORY-Tabelle mit sehr vielen doppelten Schlüsseln haben (viele Indexeinträge enthalten denselben Wert), dann laufen Updates, die Schlüsselwerte betreffen, sowie sämtliche Löschoperationen deutlich langsamer. Wie viel langsamer, hängt von dem Ausmaß der Schlüsselduplikation ab (umgekehrt proportional zur Indexkardinalität). Um dieses Problem zu vermeiden, verwenden Sie einen BTREE-Index.

Quelle: http://dev.mysql.com/doc/refman/5.1/de/memory-storage-engine.html

Ich habs ausprobiert: per Default hast du in MEMORY-Tabellen einen HASH-Index.

Du könntest mal probieren, ob es mit einem BTREE-Index besser klappt.

Mehr fällt mir aber auch nicht ein.

mfg, metax.

 

[easteregg]

beeindrucken, das wirkt zumindest so, dass der querie nichtmehr als einer ohne index gehändelt wird.
ich muss mal wegen dem speed gucken, ob das unterschiede macht.

edit: das macht auch nen unterschied von 0,0001 btree zu 0,0003 ohne index! und auch bei dem normalen hash index nimmt der diesen tatsache nicht und is mit 0,0003 wesentlich langsammer!
beeindruckend, wieder was gelernt und herzlichen dank!

 

[GrafZahl]

allein der strukturelle unterschied zwischen hash und btree macht schon deutlich warum btree an dieser stelle funktioniert, hash aber nicht ...

bei einem hash basierten index, wird der schlüssel-wert durch eine hashfunktion geschickt, und anschließend der hashwert in einer art liste einsortiert ... damit ist es sehr schnell möglich sehr viele unterschiedliche schlüsselwerte wiederzufinden, solange sich eben die anzahl der werte in grenzen hält, die den gleichen hash haben ...

super sache, es sei denn, du möchtest soetwas wie eine partielle oder totale ordnung haben ... der größer/kleiner vergleich erfordert eine solche ordnung ...

ein binärbaum sortiert sich gerade an einer solchen ordnung ... hier erfordert das auffinden eines spezifischen index werts zwar stets eine suche (binäre suche ist allerdings relativ schnell, aber langsamer als die ideale suche mittels hash), aber wenn dieser wert gefunden wurde, ist es sehr einfach dann alles zu identifizieren was links oder rechts davon im baum steht, respektive gemäß der ordnung größer oder kleiner ist ...

man kann derartige indizes auch kombinieren, in dem die hashtable nicht auf die zeile verweist, sondern auf den knoten im binärbaum, der dann auf die zeile verweist ... aber ich weiß nicht ob mysql das kann ... zudem bedeutet dies zusätzlichen platzverbrauch für den index, und zusätzliche operationen für die pflege des index ...