Faktor 214361:1
Am Wochenende schrie eine MySQL4-Datenbank über Nagios um Hilfe: die Server-Last war auf knapp über 10 angestiegen. Also - kurz per SSH auf den Server und Problem lokalisiert: mit “show processlist” zeigt MySQL eine Liste aller aktiven Prozesse (klingt irgendwie einleuchtend) 
Nun, in dieser Liste befanden sich etwa 15 Instanzen der selben Abfrage: select count(*) from xxx where month(date)=5 and year(date)=1997 and textfeld = ‘yyy’; (Spaltennamen geändert)
Also habe ich mir die Tabelle mal näher angesehen. Darin sind etwas über 200.000 Einträge verzeichnet - aber kein Index. Das heißt, die o.g. Abfrage durchsucht jedesmal alle 214.361 Datensätze (nennt sich dann “Full Table Scan”). Ganz leicht lässt sich das sehen, wenn man sich den Ausführungsplan für den SQL-Befehl ausgeben lässt (einfach ein DESCRIBE vor das SELECT setzen).
Ich war dann mal so frei, einen Index über die Spalte mit den Textschlüsseln zu erzeugen. Ergebnis: die Abfrage kann komplett über den Index bearbeitet werden - es ist nur noch ein Zugriff auf die Datensätze notwendig (für den Zieldatensatz). Das entspricht einer Optimierung von 214361:1 
Der Kunde freute sich dann auch über meine ausführliche Mail zu dem Thema:
sorry und gleichzeitig vielen Dank für Ihre Erklärung.
Was wäre ich nur ohne Sie. Sollte mir vielleicht irgendwann mal etwas professionelle Unterstützung suchen.
Ach - dafür sind wir doch gerne da. 
Der vom Kunden angebotene Dienst wächst aber auch erheblich - ich vermute mal dass zum Zeitpunkt der Erzeugung o.g. Tabelle nicht abzusehen war, dass diese mal so anwächst…