• microslow, ermöglicht die Anzeige der Querydauer in Millisekunden im slowlog
• execution plan, zeigt informationen über den Ausführungsplan im slowlog
• InnoDB statistics, zeigt erweiterte InnoDB Auswertungen während der Query Ausführung im slowlog
• Google patch mit Benutzerstatistik und Statistiken über Tabellen- und Indexnutzung

Mehr Informationen gibt es im entsprechende Mysql Performance Blog – Percona Patches.

Der Kunde hat für das Staging seiner Webanwendung zwei unterschiedliche Server. Sowohl Hardware als auch Betriebsystem sind identisch eingerichtet. Die Konfigurationsdatei für die Datenbanken sind ebenfalls gleich. Der Unterschied ist jedoch, dass auf einem System ein und die selbe Anfrage 1 Sekunde benötigt. Auf dem anderen System wartet man bis zu 5000 Sekunden. Ein EXPLAIN mit dem MySQL Client brachte nur die Gewissheit: Der existierende Index wird auf dem einen System nicht verwendet.

mysql> EXPLAIN (eine SELECT Anfrage)
+-------+--------+---------------+---------+---------+----------------+--------+---------------------------------+
| table | type   | possible_keys | key     | key_len | ref            | rows   | Extra                           |
+-------+--------+---------------+---------+---------+----------------+--------+---------------------------------+
| p     | ALL    | idx_on_column | NULL    |    NULL | NULL           | 3588047| Using temporary; Using filesort |
+-------+--------+---------------+---------+---------+----------------+--------+---------------------------------+

Erst stand der Verdacht im Raum, dass der Index auf dem einen System nicht in den Arbeitsspeicher passt, und aus diesem Grund nicht verwendet wird. Doch ausreichend Arbeitsspeicher stand zur Verfügung. Dann erinnerte ich mich vage, dass ich mal etwas in der MySQL Dokumentation zum Thema Index gelesen hatte. Die Kardinalität eines Index sollte nach dem Anlegen mit Hilfe von ANALYZE TABLE bzw. mysqlcheck neu berechnet werden.

mysqlcheck -u USER -p PASSWORD --analyze DB_NAME [TABLE_NAME]

Und tatsächlich wurde ab diesem Moment der entsprechende Index für die Anfrage verwendet. Mit Hilfe der Kardinalität kann MySQL entscheiden, ob ein Index für eine Anfrage verwendet werden kann, oder nicht. Bei fehlerhafter Kardinalität kann es vorkommen, dass die Entscheidung über das für und wider eines Index falsch getroffen werden.

Diese Art der Nachhilfe braucht MySQL allerdings nur beim Tabellentyp MyISAM. Der neuere Typ InnoDB ist deutlich besser in der Lage auszuwerten, ob und welche Indizes für eine bestimmte Anfrage benutzt werden können.

Neulich wollte ich in einer kleinen Rails Web-Applikation (siehe aktuelle Literatur) eine Ansicht einer 1:n Beziehung zweier Objekte in Listenform erstellen. Die Anforderung war allerdings, die Liste nach der Anzahl der Kinder zu sortieren und dabei die Objekte zuerst anzuzeigen, die keine Kinder haben.

[ad#vert-banner]

Damit die Ergebnismenge des SELECT Statements auch die Eltern Objekte enthält, die keine Kinder besitzen, muss ein LEFT JOIN verwendet werden. Grundsätzlich ist das zwar etwas mehr Aufwand für die Datenbank, aber dennoch schaffbar, ohne eine Ewigkeit warten zu müssen. Mit Hilfe von Indizierungen lässt sich die ganze Sache auch hinreichend beschleunigen. Das folgende SQL Statement erfüllt diese erste Anforderung:

SELECT p.name, c.name
FROM parents AS p
LEFT JOIN children AS c
ON p.id=c.parent_id

Allerdings fehlt hier die Sortierung. Das zweite Problem ist, dass das Feld c.name für alle kinderlosen Eltern NULL ist, und somit nicht gezählt werden kann. Folgendes Statement behebt zwar das Problem, aber die Ausführung braucht bei großen Tabellen Jahre.

SELECT IF(c.id IS NULL,0,COUNT(*)) AS kids, p.name
FROM parents AS p
LEFT JOIN children AS c ON p.id=c.parent_id
ORDER BY kids
GROUP BY p.id

Die lange Ausführungsdauer hat vor allem einen Grund: Die Sortierung geschieht auf einer Spalte, die effektiv nicht existiert, sondern erst zur Laufzeit mit Hilfe der Count Funktion erzeugt wird. Das heißt es muss erst ein kompletter Join über beide Tabellen durchgeführt werden, ehe eine Sortierung stattfinden kann. Auch eine Limitierung der Ergebnisliste mit Hilfe von LIMIT ändert daran nichts, denn die würde erst nach der Sortierung durchgeführt.

Um diese lange Wartezeiten zu vermeiden, habe ich mir folgendes überlegt: Man baut in die Tabelle der Elternklasse eine Spalte ein, die die Anzahl der Kinder speichert. Nun muss “nur noch” beim hinzufügen und löschen eines Kindes diese Spalte gepflegt werden. Das heißt, meine Applikation ist für die Datenintegrität zuständig.

Zurück zu Rails, denn da ist dieses Funktionalität bereits an Board. Getreu dem Motto “Konvention über Konfiguration”, erzeugt man lediglich die Spalte in der Tabelle der Elternklasse. Diese trägt den sprechenden Namen <kindertabelle>_count also in diesem falls children_count. In der Kinderklasse wird nun noch deklariert, dass der Zähler automatisch aktualisiert wird.

class Child < ActiveRecord::Base
  belongs_to :parent, :counter_cache => true
end

Und siehe da, nun lässt sich eine normaler Finder verwenden, um den View aufzubauen. Komplett ohne JOIN!

@parents = Parent.find(
  :all,
  :limit => 20,
   ffset => @parent_pages.current.to_sql[1],
   rder => "children_count ASC, parent ASC")

Da jetzt nur noch real existierende Spalten für die Sortierung verwendet werden und eine effektive Limitierung der Ergebnismenge möglich ist, dauert die Anfrage nur noch wenige ms.

Thx Rails!