RootForum Community

Hallo!

Ich habe folgende Tabelle:
--
-- Tabellenstruktur für Tabelle `bayes_token`
--

CREATE TABLE `bayes_token` (
`id` int(11) NOT NULL default '0',
`token` char(5) NOT NULL default '',
`spam_count` int(11) NOT NULL default '0',
`ham_count` int(11) NOT NULL default '0',
`atime` int(11) NOT NULL default '0',
PRIMARY KEY (`id`,`token`),
KEY `bayes_token_idx1` (`token`),
KEY `bayes_token_idx2` (`id`,`atime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Wie sicherlich schon einige erkennen handelt es sich dabei um eine Tabelle des Spamassassin.
Mit dem Spamassassin wird ein script mitgeliefert dass die alten Einträge entfernt und so die DB aktuell und klein bzw. schnell hält.
Das skript macht selects von der Art:
SELECT count( * ) FROM `bayes_token` WHERE id =1 AND atime >1224012215;
Diese dauern mitunter ziemlich lange. Laut slow query log max. sogar 11410 Sekunden.
EXPLAIN EXTENDED SELECT count( * ) FROM `bayes_token` WHERE id =1 AND atime >1224012215
liefert:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE bayes_token ref PRIMARY,bayes_token_idx2 bayes_token_idx2 4 const 95779 Using where; Using index

Ich versteh nun zB nicht warum Mysql einen ref select macht und keinen range select...? Und warum dies solange dauert. Hatte bis jetzt immer nur mit großen MyIsam Tabellen zu tun (10Gb aufwärts) und die flutschten wenn man den Index benutzte. Bei der Tabelle versteh ichs leider nicht.
Die verwendete MySQL Version ist übrigens: 5.0.22

Danke schonmal im voraus
Bru

naja anscheinend benutzt er ja den index:

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE bayes_token ref PRIMARY,bayes_token_idx2 bayes_token_idx2 4 const 95779 Using where; Using index

laut dem explain benutzt er den bayes_token_idx2 index. Was ja auch stimmen würde.

MySQL Version ist 5.0.22
OS ist Ubuntu Dapper Dake

Ok, sorry hier nochmal der formatierte Eintrag.

mysql> EXPLAIN EXTENDED SELECT count( * ) FROM `bayes_token` WHERE id =1 AND atime >1224012215 G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: bayes_token
type: ref
possible_keys: PRIMARY,bayes_token_idx2
key: bayes_token_idx2
key_len: 4
ref: const
rows: 257466
Extra: Using where; Using index
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

jetzt sieht man auch schön dass er eh nur den bayes_token_idx2 index verwendet. Ist aber trotzdem ziemlich langsam... :(
Und warum sollte er 257000 zeilen scannen um ein count(*) auf einen index herauszufinden...

Brubaker wrote:Und warum sollte er 257000 zeilen scannen um ein count(*) auf einen index herauszufinden...

http://www.google.de/search?q=jfgi&ie=u ... =firefox-a
http://www.google.de/search?q=innodb+co ... =firefox-a
http://www.mysqlperformanceblog.com/200 ... db-tables/

Danke erstmal, aber den Beitrag kenn ich auch schon ;)

Das Problem ist nur dass es darin um count(*) ohne where condition geht. Ich hab aber eine where condition...

Achja ich hab das Problem jetzt mehr oder weniger umgangen indem ich die innodb buffer size einfach auf die db Größe angepasst hab und 8Gb Ram in den Server dazu gestöpselt habe.
Nur damit die count(*) mit where condition in halbwegs absehbarer zeit fertig werden.