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

tworzenie indexow dla najbardziej uzywanych koloumn??
nie tworz dla tych co nie sa uzywane .
nie uzywaj pol typu txt,blob i varchar.
zawsze przypisuj tam gdzie yto mozliwe wartosci domyslnych,
stsuj stale polaczenia z baza..
[url=http://www.mysql.com/]MYSQL.COM
Tam szukaj a nie zbladzisz

U2DATE 1
jesli ty zarzadzasz mysql'em to stosuj uproszczony system przywilejow - kilka moli-sec ^^

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.

Pomysł z kolejnymi tabelami przyszedł po zobaczeniu ile czasu zajmuje skryptom odpytanie tej bazy...

Co do dwóch baz... jest mały problem...
Polecenia są wykonywane przez:
Wspomniana metoda jest wywoływana za każdym razem, gdy ktoś pobiera plik z serwera... (szczegóły: http://forum.php.pl/viewtopic.php?t=14917)

Jak to połączyć?

(Tylko nie mówcie, że mysql.com, bo ja tej strony poprostu nie kminię... nie czytelna jakaś... )

no ale ja nie widzę problemu.
Przeciez w ten sposób możesz zastosować sie dokładnie do zaleceń podanych przezemnie.
tj.
1. zmiana sposobu zapisu danych
2. dodanie indexów (szczególnie na dacie)
Podział na kilka tabel może być nieco bardziej problematyczny, ale choć też wydaje mi się możliwy.

Więc z czym masz tak naprawdę problem?

A co do strony MySQl.com... tam jest naprawdę swietny manual ( http://dev.mysql.com/doc/mysql/en/index.html ) choć po ostatnich zmianach na ich stronie trzeba nauczyć się do niego dotrzeć