Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

erstes Select auf Tabelle sehr langsam

Dieses Thema im Forum "MySQL und MariaDB" wurde erstellt von JensG, 14 November 2013.

  1. JensG

    JensG Neuer Benutzer

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

    akretschmer Datenbank-Guru

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

    JensG Neuer Benutzer

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

    akretschmer Datenbank-Guru

    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?
     
  5. JensG

    JensG Neuer Benutzer

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

    akretschmer Datenbank-Guru

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

    gurbelunder Datenbank-Guru

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

    akretschmer Datenbank-Guru

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

    gurbelunder Datenbank-Guru

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

    akretschmer Datenbank-Guru

    Exakt, aber der Fragesteller nutzt Windows ...
     
  11. JensG

    JensG Neuer Benutzer

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

    gurbelunder Datenbank-Guru

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

    akretschmer Datenbank-Guru

    Jupps. Daher schrieb ich auch, daß das das kleinere Übel sei ...
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden