erstes Select auf Tabelle sehr langsam

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

 

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

Kalter zu warmer Cache.

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.

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

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

 

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

 

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

Code:

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

oder

Code:

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.

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

 

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

 

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...

Genau das meinte ich mit kalten / warmen Cache.

 

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, ...)

 

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

 

Exakt, aber der Fragesteller nutzt Windows ...

 

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.

 

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.

 

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