erstes Select auf Tabelle sehr langsam

[JensG]

Hallo Zusammen,

ich habe nach der Umstellung einer Datenbank von MyISAM auf INNODB ein seltsames Verhalten.
Den Grund der Umstellung will ich erst einmal nicht näher erläutern.
MySQL Version 5.5.34 unter Windows 7 64 bit
Nach einem Neustart des MySQL Servers dauern Selects die recht viele Daten zurückliefern und über
mehrere Tabellen gehen recht lange. Der 2. Aufruf über diese Tabellen ist rasend schnell.
Stoppe und starte ich den Dienst habe ich wieder das gleiche.
Ich kann dabei auch beobachten das der Arbeitsspeicher während des 1. Selects stark nach oben geht.
Was macht MySQL da ? Habe ich da etwas falsch konfiguriert... oder bildet MySQL irgendwelche
Indexe im Arbeitsspeicher oder sollte ich die Indexe zusammenfassen.
Es gibt recht viele Indizes die unter MyISAM recht gut funktioniert haben.
Ich kann auch sehen das während des Selects eine copy to tmp table stattfindet was auf Index Problem
hindeutet. Ein Explain deutet das auch an.
Hat jemand eine Idee was ich da falsch mache oder was es bei INNODB Indizes zu beachten gibt ?
Analyze Table und Optimize Table habe ich nach der Umstellung durchgeführt.
Die Daten wurden auch sauber übertragen mittels Hilfstabelle.

Vielen Dank im Vorraus
Jens

 

[akretschmer]

Hallo Zusammen,

ich habe nach der Umstellung einer Datenbank von MyISAM auf INNODB ein seltsames Verhalten.
Den Grund der Umstellung will ich erst einmal nicht näher erläutern.

Ist auch egal. Unter MySQL ist InnoDB das kleiner Übel zu MyISAM.

MySQL Version 5.5.34 unter Windows 7 64 bit
Nach einem Neustart des MySQL Servers dauern Selects die recht viele Daten zurückliefern und über
mehrere Tabellen gehen recht lange. Der 2. Aufruf über diese Tabellen ist rasend schnell.
Stoppe und starte ich den Dienst habe ich wieder das gleiche.

Kalter zu warmer Cache.

Ich kann dabei auch beobachten das der Arbeitsspeicher während des 1. Selects stark nach oben geht.
Was macht MySQL da ? Habe ich da etwas falsch konfiguriert... oder bildet MySQL irgendwelche
Indexe im Arbeitsspeicher oder sollte ich die Indexe zusammenfassen.
Es gibt recht viele Indizes die unter MyISAM recht gut funktioniert haben.

Indexe via Gießkanne zu verteilen ist nicht sonderlich sinnvoll, aber bei einem Select stören unnötige Indexe nicht.
Die stören nur bei schreibenden Operationen.

Ich kann auch sehen das während des Selects eine copy to tmp table stattfindet was auf Index Problem
hindeutet. Ein Explain deutet das auch an.

Manche Abfragen kann MySQL nur so lösen. Also via temp-tables. Ist halt - MySQL.

Hat jemand eine Idee was ich da falsch mache oder was es bei INNODB Indizes zu beachten gibt ?

Es gibt einige Schrauben, an den Du drehen kannst. Aber MySQL und viele Joins - das geht halt schlecht zusammen.

Wäre es PostgreSQL würde ich sagen: schau, was EXPLAIN (analyse, verbose) <query> sagt, aber MySQL-Explain lesen ist so spannend wie früher das "Neue Deutschland", falls Du das kennst (kommst ja aus Gera ...)


Andreas

 

[JensG]

Hallo Andreas,
danke erst einmal für die Antwort. Da werde ich wohl weiter testen und an den Schrauben drehen müssen. Ich werde mir eine Kopie der DB anlegen und mal Indizes entfernen oder zusammenfügen oder ggf. das select ändern.

An den Namen neues Deutschland kann ich mich nur noch ganz dunkel erinnern

Gruß
Jens

 

[akretschmer]

Hallo Andreas,
danke erst einmal für die Antwort. Da werde ich wohl weiter testen und an den Schrauben drehen müssen. Ich werde mir eine Kopie der DB anlegen und mal Indizes entfernen oder zusammenfügen oder ggf. das select ändern.

Nun ja, der elegante Weg wäre, zu schauen, wie oft Indexe genutzt werden:

test=*# select * from pg_stat_user_indexes ;
 relid | indexrelid | schemaname |  relname  |  indexrelname  | idx_scan | idx_tup_read | idx_tup_fetch

oder

test=*# select * from pg_stat_user_tables ;
 relid | schemaname |  relname  | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_tup_hot

und andere Möglichkeiten - die PostgreSQL bietet, MySQL aber IMHO nicht.
Jedenfalls - man kann recht gut rausbekommen, ob vorhandene Indexe überhaupt genutzt werden können. Ich hab schon bei Kunden Tabellen mit N Spalten und M Indexen gesehen, mit M deutlich größer N, und Kunde hat sich über schlechte Insert-Performance gewundert...

Von daher: Indexe ja, aber mit Verstand, nicht mit Gießkanne vergeben.

An den Namen neues Deutschland kann ich mich nur noch ganz dunkel erinnern

Tja, zu spät geboren - das war das Zentralorgan der SED, das sagt Dir vielleicht doch noch was, oder?

 

[JensG]

Also zum einen konnte ich meine Abfragen deutlich beschleunigen in dem ich per USE INDEX
explizit angewiesen habe diese Indizes zu nutzen.
Allerdings ist das eine aufwendige Sache da die Anwendung sehr groß ist und teilweise Select's beinhaltet die per Quellcode zusammengesetzt werden . Gefällt mir eigentlich nicht.

Ich habe aber eben einen sehr interessanten Artikel gefunden. Das Verhalten scheint bei INNODB Nutzung wohl normal zu sein.
http://www.fromdual.com/warming-up-innodb-buffer-pool-during-start-up

Was die SED war das weiß ich schon noch, ich war zur Wende 15

Gruß
Jens

 

[akretschmer]

Also zum einen konnte ich meine Abfragen deutlich beschleunigen in dem ich per USE INDEX
explizit angewiesen habe diese Indizes zu nutzen.

Planner hints, hat auch Oraggle. Die PG-Core-Entwickler lehnen sowas z.B. ab und sind der Meinung, wenn man sowas braucht, ist der Planner zu doof, es wäre besser, diesen zu verbessern. Auch ein Ansatz...

Ich habe aber eben einen sehr interessanten Artikel gefunden. Das Verhalten scheint bei INNODB Nutzung wohl normal zu sein.
http://www.fromdual.com/warming-up-innodb-buffer-pool-during-start-up

Genau das meinte ich mit kalten / warmen Cache.

 

[gurbelunder]

Vielleicht kann es dir auch helfen, die explain Plans zu aktualisieren, geht glaub ich auch unter MySQL.

 

[akretschmer]

Vielleicht kann es dir auch helfen, die explain Plans zu aktualisieren, geht glaub ich auch unter MySQL.

Na, ich denk, das hat was mit am Anfang leerem Cache zu tun. Hat man die Daten einmal angefaßt, geht es schnell. Mit den Plänen hat das nix zu tun. Das Problem hat so mehr oder weniger jede DB oder jedes andere System (webserver, varnish, ...)

 

[gurbelunder]

Na, ich denk, das hat was mit am Anfang leerem Cache zu tun. Hat man die Daten einmal angefaßt, geht es schnell. Mit den Plänen hat das nix zu tun. Das Problem hat so mehr oder weniger jede DB oder jedes andere System (webserver, varnish, ...)

Das wird sicher das Hauptproblem hier sein. Normalerweise startet man einen DB Server ja auch nicht andauernd durch

 

[akretschmer]

Das wird sicher das Hauptproblem hier sein. Normalerweise startet man einen DB Server ja auch nicht andauernd durch

Exakt, aber der Fragesteller nutzt Windows ...

 

[JensG]

Der Dienst wird natürlich nicht ständig neu gestartet. Mich hat es eben nur sehr gewundert
weil mir das auf meinem Entwicklungsrechner sofort aufgefallen ist.
Und ja es liegt am Anfangs leeren Cache.
Unter MyISAM hatte sich MySQL eben nicht so verhalten. Und so extrem ist mir das noch
bei keinem anderen DB System aufgefallen. Nicht bei Oracle und auch nicht MSSQL.
Ich habe hier Abfragen wie mir leerem Cache 87 sec benötigen, mit gefülltem Cache lediglich 0,2 sec. Den Unterschied finde ich schon extrem.

 

[gurbelunder]

Ich verwechsle das gerne: wars InnoDB, welcher Fremdschlüssel unterstützt? Dies kann schon erklären, warum das beim cachen was länger dauert, denn die Relationen werden ebenfalls gecached.

 

[akretschmer]

Ich verwechsle das gerne: wars InnoDB, welcher Fremdschlüssel unterstützt?

Jupps. Daher schrieb ich auch, daß das das kleinere Übel sei ...