MySQL wydajniejsze zapytania

Witam,
Załóżmy, że każdy użytkownik przy każdym wejściu na stronę dokonuje wpis do bazy danych ze swoim IP, datą, loginem i podstroną na której się znajduje oraz robi SELECT ostatnich swoich 10 rekordów WHERE nick = nick. Spowoduje to, że przy większej liczbie użytkowników takich danych będzie bardzo dużo i nie wiem, czy takie Selectowanie danych użytkownika, który długo się nie logował, więc jego rekordy będą daleko w tabeli nie będzie spowalniające.
Czy różnica w wydajności pomiędzy:

1. Wrzucaniem tego wszystkiego do jednej tabeli i potem SELECT FROM dane WHERE nick = nick
2. Dla każdego użytkownika tworzeniem własnej tabeli i SELECT * FROM dane_[nick]
   będzie znacząca, czy może dla bazy danych szukanie pojedynczego rekordu w tabeli z np. 30 000 rekordów nie będzie problematyczne?

Hej,
w tematyce Baz Danych jestem trochę greenhorn... ale myślę, że to zależy... od wielu czynników... od wielkości bazy, od częstości sięgania po logowania... od tego, ile razy sprawdzamy te logowania... czy konieczne jest sprawdzania logowań dokładnie na bieżąco... czy te logowania sprawdzamy pojedynczo, czy hurtem... itd. Ale bez wątpienia poruszasz ważny temat... Bardzo często ważniejsza od Algorytmów, procesora, itd... Jest Struktura Danych, o czym się nie zawsze pamięta, miłego... :)

Jeśli chodzi o drugie podejście, to poprawnym rozwiązaniem jest partycjonowanie tabeli, a nie robienie osobnej dla każdego użytkownika. Jednak jeśli nie będziesz miał milionów wierszy w tej tabeli, zwykły indeks powinien wystarczyć, by czas pobierania danych mieścił się w rozsądnych granicach.

1. 30000 rekordów to dla bazy pestka, nawet bez indeksów, a jeśli dodasz odpowiedni indeks na polach z warunku where to wszystko będzie śmigać nawet na bazie z milionami rekordów
2. tworzenie oddzielnej tabeli dla każdego usera to bardzo zły pomysł

Zainteresuj się takimi tematami jak memcache oraz client-side storage. Nie musisz zawsze sięgać do bazy... Ale prawdę mówiąc nie wierzę, że dojdziesz do takiej popularności, że baza zacznie niedomagać. Na razie o tym nie myśl, tylko zajmij się tym, żeby klient dostał jak najlepszy produkt.

Wydaje mi się, że index na (NICK ASC, UserLastVisit DESC) powinien załatwić sprawę wydajności zapytania typu:

SELECT * FROM TABELKA WHERE NICK=:XYZ ORDER BY UserLastVisit DESC LIMIT 10 

Do tego pewnie można partycjonować, ale czy warto dla 30k rekordów się bawić? :-)

NIe rób bazy danych w bazie danych. Po prostu ogarnij już wspomniane INDEKSY.
Powiem brutalnie : jeśli nie korzystasz z indeksów to znaczy, że ta baza danych jest Ci zupełnie na grzyba i przeszkadza tylko (zresztą normalka).
30 000 rekordow to nie jest jest nawet NIC. To mniej nawet niż pół litra na 3.
Coś to jest jak masz tabelę 2 milionami rekordów i szukasz tych, których jeszcze nie ma w drugiej tabeli gdzie jest 1.8 miliona rekordów :-) Ale to tez się a w miarę wydajnie załatwić (#pdk z outer joinem na is null).