Zitat von Thomas Schmidt schmidt@netaction.de:
Hallo Lug!
Ich habe folgende Tabelle:
CREATE TABLE pages ( sequences longtext COLLATE utf8_unicode_ci NOT NULL, revid int(11) NOT NULL, pageid int(11) NOT NULL, title varchar(250) COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (revid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Sie ist 3GB groß und enthält 550k Einträge. Die sequences sind Text.
also eine eher kleine Tabelle ...
Es gibt drei Befehle, die ich auf der Tabelle ausführe: INSERT INTO pages (sequences,revid,pageid,title) VALUES(:sequences,:revid,:pageid,:title) SELECT sequences FROM pages WHERE revid=:revid (30x pro Sekunde)
Die sollte rasend schnell gehen, da Suche nach einem PK.
SELECT count(*) AS pages FROM pages
Jetzt gibt es zwei Probleme. Erstens wächst der Speicherbedarf von MySQL fast auf die Größe der Tabelle. Gebe ich ihm nicht den RAM, also momentan innodb_buffer_pool_size=3G, wird die Ausführungszeit der Queries extrem lang, und die CPU-Last steigt ins Unermessliche.
welcher Anfragen, da sind 2. Die Suche nach dem PK sollte IMHO nicht leiden.
Zweites kostet es 25% CPU, wenn ich jede Sekunde das SELECT count(*) ausführe. Egal, ob sich an der Tabelle überhaupt etwas ändert. Diesen
Ich nix MySQL, aber unter PG würde dies auch dauern, da es einen Seq-Scan erfordert. Normalerweise braucht man dies nicht, also die exakte Anzahl. Oft reicht eine grobe Schätzung der Gesamtanzahl, sie gilt ja streng genommen auch nur für die konkrete TX, in der Du das abfragst. 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.
SELECT habe ich testweise in einen VIEW gepackt, aber das ändert
Ein VIEW ist eh nix weiter als ein Alias für einen SELECT.
Andreas