Zitat von Thomas Schmidt schmidt@netaction.de:
Vielen Dank Andreas!
Gerade habe ich "OPTIMIZE pages" ausgeführt. Anscheinend war der Primary Key wirkungslos, da alle Daten in der selben Datei lagen. Das Optimize müsste die Keys nochmal in einer zweiten Datei extra gespeichert haben.
Effekt ist, dass deutlich weniger RAM verbraucht wird. Ab wann die Datenbank wieder mangels Speicher langsam wird, wird sich zeigen.
In einem $anderen_db_system gibt es den Befehl EXPLAIN ANALYSE <query>, wo man sehr schön u.a. Dinge wie geschätzte und reale Anzahl Ergebnisssätze, genutze Indexe, Cache Hit/Miss, Größe temp. Files und einiges mehr sehen kann ... bei MySQL ist das alles ja eher Blindflug.
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert.
Also, entweder guggst Du in den Statistiken nach einer Schätzung (in PG wäre dies pg_class.reltuples), oder aber führst über einen TRIGGER einen exakten Counter.
Die Schätzung liegt um Faktor zwei daneben. Epic fail. Auf 10% sollte die Zahl schon stimmen.
Ich möchte auch wissen, wie viele Einträge in der letzten Sekunde dazugekommen sind. Der TRIGGER ist natürlich etwas unhandlich, aber wohl die beste Lösung.
Ja, wenn es genau sein soll, ...
Andreas