Optymalizacja bazy danych [nie chodzi OPTIMIZE] Opcje

[Bakus]

Dla testów przeniosłem logi serwera Apache do MySQLa...
Niestety zaskoczyła mnie jedna rzecz...
Log od 29 marca, g. 02:53 do 31 marca do godziny 23:59 urusł do 42 294 rekordów (6.9 MB)
Log dla kwietnia już liczy ponad 70 tys. rekordów... Jak zrobić by zapytania do bazy danych nie trwały po pare (naście) sec. ?

Przykładowe zapytanie do bazy
[sql:1:627e450951]SELECT `useragent` , count(*) AS count FROM `log_042004` GROUP BY `useragent` ORDER BY count DESC LIMIT 10;[/sql:1:627e450951]

Nie wiedziałem jak inaczej zobrazować strukturę bazy, więc wrzucam wam kod ją tworzący...
[sql:1:627e450951]CREATE TABLE `log_032004` (
`id` int(11) NOT NULL auto_increment,
`d` char(2) default NULL,
`H` char(2) default NULL,
`i` char(2) default NULL,
`s` char(2) default NULL,
`method` char(3) NOT NULL default '',
`url` text NOT NULL,
`query` text NOT NULL,
`referer` text NOT NULL,
`rhip` varchar(15) NOT NULL default '',
`useragent` varchar(255) NOT NULL default '',
`https` char(2) NOT NULL default '',
PRIMARY KEY (`id`)
) TYPE=MyISAM AUTO_INCREMENT=42301;[/sql:1:627e450951]

Już zrobiłem, by każdy miesiąc był zapisywany do kolejnej tabeli, ale perspektywa zbierania 11500 kolejnych rekordów statystyk nie rysuje się kolorowo...

Jak zoptymalizować tą bazę i/lub zapytania by to chodziło szybciej

[DeyV]

1. dlaczego data w 4 polach, zamiast w 1? Pola date, lub timestamp zajmują około 3 bajtów. Tak - jest tego kilka razy więcej. ( o ile dobrze zrozumiałem znaczenie kolumn d, i , h, s)

2. jeśli potrzebujesz tylko liczbę różnych przegądarek w danym dniu, godzinie itp, zrobiłbym to nieco inaczej.

Podzieliłbym te informacje na 2 tabele. W 1 przechowywałbym wszystkie informacje o tym skąd, jaki adres, przeglądarka itp. było.
Z uwagi na to, że są to dane w miarę często powtażające - nie ma sensu zapisywać ich tysiące razy.
Tak więc - można tylko sprawdzić, czy taka kombinacja jeszcze się nie pojawiła - jeśli już jest - wystarczy w 2 tabeli zwiększyć jakiś licznik dla tego typu wpisu, albo nawet datę zdażenia i id tego typu wpisu.

3. nie widzę sensu by generować kolejne tabele dla takich danych. MySQL bardzo dobrze radzi sobie z tabelami któe mają nawet mln rekordów, więc jeśli będą dobrze przygotowane indexy (np. koniecznie po dacie) to powinno to chodzić dobrze nawet przy bardzo dużych ilościach danych i sporym ruchu.