Czy jeżeli tabela ma bardzo dużo wierszy, to jej podział na mniejsze tabele (np. po 100 000 wierszy każda) mógłby przyśpieszyć wykonywanie zapytać?
Np. tabela przechowująca dane osób mogłaby być podzielona "alfabetycznie" na tabele:
osoby_a, osoby_b, osoby_c, itd.
Gdzie tabela_a przechowuje dane osób, których imię zaczyna się od "A".

[PHP] pobierz, plaintext 
swich ( PobierzePierwszaLitere($imie) )
{
   case ("a")
      $nazwa_tabeli = "osoby_a";
      break();
   case ("b")
      $nazwa_tabeli = "osoby_b";
      break();
      itd....
}
[PHP] pobierz, plaintext 

Czy wówczas np. takie zapytanie:

[SQL] pobierz, plaintext 
selec * FROM $nazwa_tabeli WHERE $imie LIKE 'Adam';
[SQL] pobierz, plaintext 

wykonywałaoby się szybciej niż gdyb dane wszystki osób były przechowywane w jednej tabeli?

ee wtedy więcej miejsca zajmujesz. nie wiem po co oddzielna tabela dla każdej pierwszej litery, skoro można zrobić tabelę imiona a w warunku dawać coś takiego:
LIKE '$pierwsza_litera%'

Nie tyle, co miejsca, a pamięci. Spróbuj sortować/grupować wyniki z takiego czegoś.

Jedyne, co mi przychodzi do głowy, to partycjonowanie: http://dev.mysql.com/doc/refman/5.1/en/par...g-overview.html

Ale zaznaczam, jeszcze w temat się nie zagłębiałem, więc mogę siać herezje.

To czego szukasz nazywa się partycjonowaniem bazy danych. I może przyśpieszyć wykonywanie zapytań, jednak zależy to od wielu czynników, info na ten temat można znaleźć na internecie.

Implementować to jednak należy raczej po stronie bazy danych poprzez przeznaczony do tego mechanizm partycjonowania. A nie poprzez jakiś mechanizm zrobiony przez siebie. Bo możesz mieć problemy gdy będziesz musiał wyciągać jakieś dane z wielu partycji. Np. w jakimś zbiorczym raporcie itp.

Odnośnie samych partycji to powinny one w jak najbardziej równomierny sposób rozkładać pomiędzy siebie obciążenie, zarówno dotyczące ilości wierszy jak i ilości zapytań do pojedynczej partycji. I podział na pierwszą literę imienia, wydaje mi się nieoptymalnym rozwiązaniem pod tym względem bo myślę, że niektóre imiona są w znaczący sposób bardziej popularne od innych. Ale oczywiście sens takiego partycjonowania zależy od szczegółów projektu i w Twoim przypadku być może ma to sens.

Prosta sprawa, wystarczy zapłacić, powiedzmy 20 tyś euro, za konsulacje komuś kto zna się na bazach danych, a ten zrobi Ci to porządnie.
Niestety ale tak to wygląda, specjalistów w tej dziedzinie jest mało, sama tematyka jest bardzo, bardzo, bardzo, bardzo, bardzo, bardzo, bardzo trudna i złożona.

Administrowanie bazą czyli między innymi kwestia partycjonowania czyli fizycznego ułożenia danych na nośniku to jedno.
Druga sprawa to programowanie - konstrukcja zapytania i wiedza na temat jak optymalizator je zmodyfikuje.
Z optymalizatorami zapytań jest o tyle "wesoło", że są one najgłębiej skrywaną tajmenicą producenta.

Ja tutaj nawet nie rzuciłem najbladszego światła na temat.
Przeczytałem na ten temat pare książek, wiem z nich, że z bazami wcale nie jest tak hop-siup jakby się mogło komuś wydawać. Tak jak napisałem wyżej, temat jest niezmiernie skomplikowany.

Jeśli mam dawać jakieś rady, to mogę dać jedną... Zakładaj indeksy i módl się.

Pozdrowienia.

wNogachSpisz - nie siej paniki.

do autora pytania: jest kilka sposobów na osiągnięcie dobrej wydajności.
po pierwsze założenie indeksu na imię. różnych imion w Polsce jest 1-1,5k, różnorodność więc jakaś tam jest. istnieje szansa, że taki indeks załatwi Ci sprawę.
jeśli rekordów jest b. dużo (nie, 1mln rekordów to NIE jest dużo) to można rozbijać strukturę: wydzielić imiona do osobnej tabeli (będzie max 2k wierszy, w tym int autoincrement) a w tabeli głównej dać klucz obcy. taki index będzie szybszy.

kolejne mechanizmy możliwe do wykorzystania to wspomniane partycjonowanie. z tym, że dla małych zbiorów danych (mniej niż powiedzmy 100mln) raczej wzrost wydajności nie będzie większy niż dobre zaindeksowanie tabel. poza tym są pewne ograniczenia - więcej znajdziesz tutaj: http://www.slideshare.net/datacharmer/part...mysql-51-and-55

W takim razie ile to jest dużo rekordów?

Aż tak dużej ilości rekorodów w swojej bazie danych nie będę miał, więc będzie to pewnie dobrze chodzić nawet bez żadnych optymializacji, ale dobrze jest na przyszłość wiedzieć, że są takie rzeczy jak partycjoowanie i indeksy.