KonKorT
Lt. Commander
- Registriert
- Jan. 2004
- Beiträge
- 1.590
Hallo,
wie der Titel bereits verrät, werden durch einen Fulltext-Index urplötzlich alle UPDATE-Querys unheimlich langsam.
Zur Vorgeschichte sei folgendes gesagt:
Der Seitenaufbau eines Berichts und Tests betrug bislang immer rund 0,012 Sekunden. Heute bemerkte ich, dass die Seitenaufbauzeit - aber nur bei Berichten und Tests - deutlich zugenommen hat: 0,03 Sekunden. Egal welcher Artikel, immer rund 2,5x so langsam wie sonst.
Habe dann die jeweiligen Dateien durchforstet, um die Stelle zu finden, die dafür verantwortlich ist. Die Ursache war schnell herausgfunden. Nachfolgende Query beanspruchte allein für sich selbst 0,015 Sekunden!
In der Codepassage wird die Anzahl der Hits des jeweiligen Berichts bzw. Tests (in diesem Fall) um eins erhöht.
Daraufhin habe ich mich auf Ursachenforschung betrieben, denn eine lächerliche UPDATE-Query sollte im Regelfall nicht so viel Performance ziehen. Gesucht, gefunden! Der FULLTEXT Index, der auf der Spalte text vom Typ text sitzt, ist schuld an der unglaublich lahmen UPDATE-Query. Nach Entfernung des Indexes lief die UPDATE-Query mit gewohnten 0,0007 Sekunden.
Daraufhin habe ich auch andere UPDATE-Querys innerhalb der Tabelle ausprobiert und wirklich alle UPDATE-Querys sind dermaßen langsam, wenn der Index gesetzt ist. Auch habe ich mehrmals die Tabelle optimiert und repariert - Erfolg sollte sich aber nicht einstellen.
Der Fulltext Index sitzt schon seit mehreren Monaten auf den beiden Tabellen berichte und tests und verrichtete bislang anstandlos seinen Dienst - also um die "normale" Verzögerung durch Setzen eines Fulltext Indexes kann es sich hierbei nicht handeln. Auch ist definitiv auszuschließen, dass die Tabelle(n) defekt ist, denn ich habe bereits eine dupliziert und diese lief ähnlich langsam mit dem Index.
Erbitte Eure Hilfe! Vielleicht habt Ihr ja eine Idee, wo der Hase begraben liegt.
Nachtrag 1: 24.08.2007 - 18:52 Uhr
Mittlerweile konnte ich noch die interessante Bemerkung machen, dass die Geschwindigkeit der UPDATE Query abhängig von der Textlänge des Datensatzes ist, der über WHERE id = '$id' angesprochen wird. Wird also beispielsweise dort der Artikel mit der id 26 herausgepickt, der nurmal angenommen eine Textlänge von 40.000 Zeichen besitzt, ist die Query langsamer, als wenn die id 14 wäre, wo die Textlänge 10.000 Zeichen betrüge. Vielleicht hilft es ja zur Problemlösung.
Nachtrag 2: 25.08.2007 - 20:13 Uhr
Womöglich hilft es, wenn ich noch ein paar weitere Details preisgebe. Die Tabelle ist vom Typ MyISAM und besitzt folgende Struktur:
- id - smallint(5)
- name - varchar(48)
- ueberschrift - varchar(64)
- text - text
- kategorie - tinyint(3)
- anzahl - mediumint(9)
- topicid - mediumint(9)
- postid - mediumint(9)
- datum - date
Indizes wurden folgende gesetzt:
PRIMARY auf id
INDEX auf datum
FULLTEXT auf name und text
FULLTEXT auf name
wie der Titel bereits verrät, werden durch einen Fulltext-Index urplötzlich alle UPDATE-Querys unheimlich langsam.
Zur Vorgeschichte sei folgendes gesagt:
Der Seitenaufbau eines Berichts und Tests betrug bislang immer rund 0,012 Sekunden. Heute bemerkte ich, dass die Seitenaufbauzeit - aber nur bei Berichten und Tests - deutlich zugenommen hat: 0,03 Sekunden. Egal welcher Artikel, immer rund 2,5x so langsam wie sonst.
Habe dann die jeweiligen Dateien durchforstet, um die Stelle zu finden, die dafür verantwortlich ist. Die Ursache war schnell herausgfunden. Nachfolgende Query beanspruchte allein für sich selbst 0,015 Sekunden!
Code:
mysql_query("UPDATE tests SET anzahl = anzahl+1 WHERE id = '$id'");Daraufhin habe ich mich auf Ursachenforschung betrieben, denn eine lächerliche UPDATE-Query sollte im Regelfall nicht so viel Performance ziehen. Gesucht, gefunden! Der FULLTEXT Index, der auf der Spalte text vom Typ text sitzt, ist schuld an der unglaublich lahmen UPDATE-Query. Nach Entfernung des Indexes lief die UPDATE-Query mit gewohnten 0,0007 Sekunden.
Daraufhin habe ich auch andere UPDATE-Querys innerhalb der Tabelle ausprobiert und wirklich alle UPDATE-Querys sind dermaßen langsam, wenn der Index gesetzt ist. Auch habe ich mehrmals die Tabelle optimiert und repariert - Erfolg sollte sich aber nicht einstellen.
Der Fulltext Index sitzt schon seit mehreren Monaten auf den beiden Tabellen berichte und tests und verrichtete bislang anstandlos seinen Dienst - also um die "normale" Verzögerung durch Setzen eines Fulltext Indexes kann es sich hierbei nicht handeln. Auch ist definitiv auszuschließen, dass die Tabelle(n) defekt ist, denn ich habe bereits eine dupliziert und diese lief ähnlich langsam mit dem Index.
Erbitte Eure Hilfe! Vielleicht habt Ihr ja eine Idee, wo der Hase begraben liegt.
Nachtrag 1: 24.08.2007 - 18:52 Uhr
Mittlerweile konnte ich noch die interessante Bemerkung machen, dass die Geschwindigkeit der UPDATE Query abhängig von der Textlänge des Datensatzes ist, der über WHERE id = '$id' angesprochen wird. Wird also beispielsweise dort der Artikel mit der id 26 herausgepickt, der nurmal angenommen eine Textlänge von 40.000 Zeichen besitzt, ist die Query langsamer, als wenn die id 14 wäre, wo die Textlänge 10.000 Zeichen betrüge. Vielleicht hilft es ja zur Problemlösung.
Nachtrag 2: 25.08.2007 - 20:13 Uhr
Womöglich hilft es, wenn ich noch ein paar weitere Details preisgebe. Die Tabelle ist vom Typ MyISAM und besitzt folgende Struktur:
- id - smallint(5)
- name - varchar(48)
- ueberschrift - varchar(64)
- text - text
- kategorie - tinyint(3)
- anzahl - mediumint(9)
- topicid - mediumint(9)
- postid - mediumint(9)
- datum - date
Indizes wurden folgende gesetzt:
PRIMARY auf id
INDEX auf datum
FULLTEXT auf name und text
FULLTEXT auf name
Zuletzt bearbeitet:
