mixmastertobsi: mysqltuner.pl

Hallo, um meine MySQL zu optimieren, habe ich das Tool mysqltuner.pl benutzt.

Nun bekomme ich folgende Meldungen, kann damit aber nicht viel anfangen

  • Limit charset for column to one charset if possible for
  • Limit collations for column to one collation if possible for

Ich bin alle Tabellen durch gegangen und finde nur UTF8 Kollation. Warum bekomme ich diesen Error, oder an was könnte es noch liegen?

  • Adjust your join queries to always utilize indexes

WAS ist hier konkret zu machen?

-query_cache_type (=0)

Wenn ich hier den query_cache_type auf 0 setze, sind meine Abfragen sehr sehr langsam. Was mache ich falsch?

  1. Hallo

    Nun bekomme ich folgende Meldungen, kann damit aber nicht viel anfangen

    • Limit charset for column to one charset if possible for
    • Limit collations for column to one collation if possible for

    Ich bin alle Tabellen durch gegangen und finde nur UTF8 Kollation.

    Heißt, deine Spalten (colums) haben „nur einen“ Charset (limit … to one charset). Mission erfüllt.

    Warum bekomme ich diesen Error, oder an was könnte es noch liegen?

    Welcher Error? Das sind Tips zur Optimierung, die offensichtlich nach einer nicht ausreichend gründlichen Prüfung der Gegebenheiten gegeben werden. Das spricht natürlich auch für die Qualität des Tools.

    • Adjust your join queries to always utilize indexes

    WAS ist hier konkret zu machen?

    Die Spalten, die den JOIN verbinden (ON tabelle1.spalte = tabelle2.spalte), sollen indizierte Spalten sein. Die Verwendung von Indizes beschleunigen die Operation im Allgemeinen.

    -query_cache_type (=0)

    Wenn ich hier den query_cache_type auf 0 setze, sind meine Abfragen sehr sehr langsam. Was mache ich falsch?

    Du setzt den query_cache_type auf 0. Wenn ich das nich missinterpretiere, wird die Abfrage nach ihrer Ausführung nun nicht mehr im Cache vorgehalten, was heißt, sie wird nun jedesmal neu ausgeführt. Das macht die Abfrage langsam.

    Tschö, Auge

    --
    Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
    Toller Dampf voraus von Terry Pratchett
    1. Heißt, deine Spalten (colums) haben „nur einen“ Charset (limit … to one charset). Mission erfüllt.

      Ich verwende ja nur einen Charset. Wo soll denn noch der "andere" Charset sein, bzw. wie kann ich den mir anzeigen lassen, ohne jetzt 150 Tabellen durchklicken zu müssen?

      Die Spalten, die den JOIN verbinden (ON tabelle1.spalte = tabelle2.spalte), sollen indizierte Spalten sein. Die Verwendung von Indizes beschleunigen die Operation im Allgemeinen.

      Ich habe ja bereits überall INDEXES gesetzt. Warum kommt also diese Meldung?

      1. Hallo

        Heißt, deine Spalten (colums) haben „nur einen“ Charset (limit … to one charset). Mission erfüllt.

        Ich verwende ja nur einen Charset.

        Dann ist doch alles gut, oder?

        Die Spalten, die den JOIN verbinden (ON tabelle1.spalte = tabelle2.spalte), sollen indizierte Spalten sein. Die Verwendung von Indizes beschleunigen die Operation im Allgemeinen.

        Ich habe ja bereits überall INDEXES gesetzt.

        Dann ist doch alles gut, oder?

        Warum kommt also diese Meldung?

        Frag den/die Entwickler, nicht mich. Vielleicht finden sie Spalten mit Texttypen und zeigen die Charset-Meldung(en). Vielleicht sehen sie JOINs und zeigen die Index-setzen-Meldung(en). Vielleicht passt es nicht zu deinen Aufgaben. Vielleicht taugt das Tool auch einfach nichts. Wer weiß? Ich nicht.

        Tschö, Auge

        --
        Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
        Toller Dampf voraus von Terry Pratchett
  2. Tach!

    Hat das Tool denn keine Anleitung zum Beheben oder eine Erklärung in seiner Dokumentation? Zur Not musst du halt in den COde schauen und die Prüfung zur Fehlermeldung analysieren.

    • Limit charset for column to one charset if possible for
    • Limit collations for column to one collation if possible for

    Ich bin alle Tabellen durch gegangen und finde nur UTF8 Kollation. Warum bekomme ich diesen Error, oder an was könnte es noch liegen?

    Ich spekuliere mal, dass diese Angaben nur implizit (vererbt) da sind und nicht explizit gemacht wurden.

    • Adjust your join queries to always utilize indexes

    WAS ist hier konkret zu machen?

    Vielleicht fehlt da ein Index auf der Join-Bedingung.

    -query_cache_type (=0)

    Wenn ich hier den query_cache_type auf 0 setze, sind meine Abfragen sehr sehr langsam. Was mache ich falsch?

    Du liest anscheinend die Dokumentation zu diesem Parameter nicht. 0 ist jedenfalls ausgeschaltet.

    dedlfix.

    1. Tach!

      Zur Not musst du halt in den COde schauen und die Prüfung zur Fehlermeldung analysieren.

      Ich hab ihn gefunden und zu diesen Aussagen

      • Limit charset for column to one charset if possible for
      • Limit collations for column to one collation if possible for

      findet man die Querys, die dazu ausgeführt wurden. Eine davon ist

      select DISTINCT(CHARACTER_SET_NAME) from information_schema.COLUMNS where CHARACTER_SET_NAME IS NOT NULL AND TABLE_SCHEMA ='$_'
      

      Die kann man sich ja kopieren und ein wenig ändern, so dass die Spaltennamen angezeigt werden. Zum Beispiel das DISTINCT entfernen und den Spaltennamen hinzufügen oder GROUP BY auf CHARACTER_SET_NAME und GROUP_CONCAT() auf die Spaltennamen.

      dedlfix.

      1. Hallo, also das mit dem Charset habe ich nun hinbekommen.

        Nun habe ich noch einen error/empfehlung

        query_cache_limit (> 8M, or use smaller result sets)

        join_buffer_size (> 16.0M, or always use indexes with joins)

        Daraufhin habe ich die Werte auf 32 und 64 erhöht und dann bekomme ich die Empfehlung, noch weiter hoch zu gehen. Was wäre hier ein guter WErt?

        query_cache_limit (> 32M, or use smaller result sets)

        join_buffer_size (> 64.0M, or always use indexes with joins)

        1. Tach!

          Daraufhin habe ich die Werte auf 32 und 64 erhöht und dann bekomme ich die Empfehlung, noch weiter hoch zu gehen. Was wäre hier ein guter WErt?

          Das hängt von deinen Gegebenheiten ab. Daumeregel: mehr Cache bei mehr Zugriffen kann nicht verkehrt sein.

          Wenn du es optimal haben möchtest, musst du Statistiken zu Cache-Treffern und -Fehlschlägen auswerten. MySQL liefert diese Daten, Tools wie Munin können sie abfragen und hübsch aufbereiten.

          dedlfix.

          1. Das wäre meine aktuelle Config. Hast Du mir hier einen Tipp, oder ist es soweit OK. Speicher etc. ist ausreichend vorhanden.

            
            query_cache_size = 256M
            query_cache_limit = 32M
            join_buffer_size = 64M
            table_open_cache = 39390
            innodb_buffer_pool_size = 3G
            innodb_log_buffer_size = 16M
            
            innodb_log_file_size = 1G
            innodb_buffer_pool_instances = 3