Optymalizacja jest ważna

Okazuje się, że nawet ja mogę spartolić prostą rzecz. Zrobiłem niedawno statystyki - "ilość osób na stronie" - w bardzo prosty sposób:

CREATE TABLE `_stats` (
  `data` timestamp(14) NOT NULL,
  `ip` varchar(20) NOT NULL default '',
  UNIQUE KEY `ip` (`ip`),
  KEY `data` (`data`)
) TYPE=MyISAM;

REPLACE INTO _stats VALUES (NOW(),'$ip')
SELECT count(*) as ILE FROM _stats WHERE data+1500 > now()
DELETE FROM _stats WHERE TO_DAYS(data)+2 < TO_DAYS(now())

czyli trzymałem w tabeli SQL numery IP, liczba osób na stronie = liczba ipków, które odwiedziły stronę w ciągu ostatnich 1500 sekund. Jak widać w tabeli były trzymane IPki z ostatnich 2 dni. Zrobiłem to na szybko, nie przykładając zbytniej wagi do problemu.

Aż tu nagle okazało się, że przy 70 userach "na stronie" serwer MySQL kopnął w kalendarz. Tabela _stats się uszkodziła, klient obiecywał mi rozkosze smażenia w smole...

Poprawiłem kod na:

REPLACE INTO _stats VALUES (NOW(),'$ip')
DELETE FROM _stats WHERE data+1500 < now()
SELECT count(*) as ILE FROM _stats

I od tej pory wszystko hula jak należy. Różnica jest taka, że w tabeli jest mniej rekordów, zamiast 3000 jest około 70 (zależy oczywiście od pory dnia).
Oprócz tego silnik bazy danych nie mieli niepotrzebnie dwa razy całej tabeli w poszukiwaniu rekordów "starszych/młodszych niż" i nie robi niepotrzebnych obliczeń przy funkcji TO_DAYS().

Jak widać na powyższym przykładzie diabeł tkwi w szczegółach i trzeba na nie zwracać uwagę, a nie robić "byle szybko".

Na domiar złego, akurat przerwałem pracę przy swoich statystykach, przegrałem plik na serwer i jak wszedłem teraz, po godzinie walki z tym błędem to oczywiście wita mnie parse error... Czyżbym się już zestarzał?

Komentarze: