Normalerweise stehe ich irgendwelchen Scripten, die Performanceverbesserungen einer Datenbank versprechen kritisch gegenüber. Zuviele Seiteneffekte sind zu beachten. Alleine schon die unterschiedliche Struktur der auf den Datenbankserver aufsetzenden Anwendungen lassen es sehr schwierig erscheinen, alles mit einem Script erschlagen zu wollen. Mein bester Freund ist Studium der Literatur der Datenbank, Beobachtung des Laufzeitverhaltens und etwas gesunder Menschenverstand. Damit bin ich bisher ganz gut gefahren.
Nun hat mich mein Kumpel auf tuning-primer.sh aufmerksam gemacht. Dieses Script wurde von Matthew Montgomery, einem MySQL Mitarbeiter geschrieben. Ich habe das Script auf meine vorhandene Installation auf dem virtuellen Rootserver laufen lassen und habe nach und nach einige der Empfehlungen des Scriptes umgesetzt und die Ergebnisse abgewartet. Vorteilhaft an dem Script ist, das es keine Änderungen selber durchführt, sondern nur Empfehlungen ausspricht zusammen mit einer Erläuterung. Beim auswerten kam ich dann schon mal an einen Punkt, wo ich merkte, das ich bisher offensichtlich die Namen der Variablen nicht immer richtig interpretiert hatte sondern mir meine eigenen Zusammenhänge vorgestellt hatte, die aber offensichtlich mit der Wirklichkeint eben nichts gemein hatten 
Aber ganz so schlimm war es dann doch nicht.
Das einzige wiklich auffällige war der Table Cache. Da habe ich wie eben geschrieben auch nicht die Zusammenhänge richtig begriffen.
TABLE CACHE
Current table_cache value = 128 tables
You have a total of 978 tables
You have 128 open tables.
Current table_cache hit rate is 0%, while 100% of your table cache is in use
You should probably increase your table_cache
Die Empfehlung ist etwas schwammig formuliert, ich habe mittlerweile dort einen Wert von 1000 eingestellt. Nun können also alle Tabellen gecached werden, das Script ist zufrieden und ich bin es auch 
Das Script schaut zuerst nach der Laufdauer der Datenbank und warnt bei Laufzeiten von <48 Stunden davor sich auf die Empfehlungen zu verlassen, weil die Datenbasis zu klein ist. Das ist auch sehr sinnvoll, denn temporäre Spitzen sollten schon mal im Beobachtungszeitraum vorgekommen sein, damit man nicht zu knapp kalkuliert. Das Script gibt Empfehlungen für:
Slow Query Log
Max Connections
Worker Threads
Key Buffer
Query Cache
Sort Buffer
Joins
Temp Tables
Table (Open & Definition) Cache
Table Locking
Table Scans (read_buffer)
Innodb Status
Fazit: Das Script ist sehr hilfreich, es hilft vor allem denjenigen die sich nicht so tief mit der Materie beschäftigen wollen und schnelle Ergebnisse brauchen. Etwas Vorsicht sollte man aber dennoch walten lassen, vor allem, wenn es sich um ein Produktivsystem handelt, denn man hat schnell einen Tippfehler gemacht, den man erst langwierig suchen muss, bevor die Datenbank wieder hochfährt
Script download:tuning-primer.sh
