Witajcie!
Zastanawiam się w jaki sposób phpMyAdmin "wie", że będzie następna strona w wynikach?
Staram się zrobić dobrą paginację bez uciekania się do zastąpienia pól za pomocą COUNT(`id`) - wymusza to na mnie podwójne wykonanie zapytania, raz na całości [która może mieć i 80 tys rekordów] a drugi raz już z limitem. Do tego problem stwarzają skomplikowane zapytania (których wyniki są jednak cachowane).

To się wyklucza wzajemnie. Paginacja to nic innego jak zliczenie i operowanie limitem. Reszta nie jest zależna od samego zapytania, a od tego jak te dane wyświetlisz.

jest jeszcze:

SQL_CALC_FOUND_ROWS

jednak nie zawsze to dobry pomysł aby dowiedzieć się dlaczego, wystarczy w google wpisać warto jednak przetestować u siebie takie rozwiązanie, bo może okazać się dużo szybsze niż 2 zapytania.

Jeśli robisz prostą przeglądarkę tabel (bez połączeń z innymi tabelami i bez warunków), to z:
SELECT * FROM information_schema.tables WHERE table_schema = 'twoja_baza_danych' and table_name='twoja_tabela'
możesz wyciągnąć podstawowe informacje jak. np. ilość rekordów (TABLE_ROWS), tylko że dla InnoDB są to wartości przybliżone... Więc tak naprawdę nie ma innego sposobu jak liczenie najpierw...

To sie robi troche inaczej.

Zalozenie ze na stronie wyswietlasz 20 wynikow. Chcesz zrobic tak ze w paginacji jest

1 - 2 - (3)- 4 >
Zalozmy ze jestes na 3 stronie, pobierasz wtedy zapytaniem z limitem 3*20, 21 wierszy (nie 20 tylko 21 poniewasz jak dostaniesz mniej niz 21 to znaczy ze nie ma nastepnej strony), a jak dostaniesz 21 to wiesz ze jest nastepna strona.

Lekka przesada.
Ja jestem za tradycyjnym count(id).
Jeżeli się mylę to mnie poprawcie ale chyba czytałem gdzieś, że count(id) nie 'liczy' wszystkiego (o ile id jest primary) tylko zwraca sumę rekordów w przeciwieństwie do count(*).

z tego co mi wiadomo to count nie zlicza wartości null
więc jeśli masz id == NULL to może go nie zliczyć przy count(id), ale przy count(*) już może zliczyć.

zróbcie sobie testy wydajności zapytania count(id), gdzie id to primary key
przecież to indeks, nie wierzę, że nie zapisałby sobie 4 bajtów na inta, a sądząc po tym, że do szukania korzysta z szukania binarnego, to musi znać granice przedziałów, więc, wg mnie to tylko odczytanie inta i zwrócenie,
oczywiście zapytanie mozna sobie wczesniej "spreparować" czy utworzyć procedurę w mysql, żeby nie tracić czasu na parsowanie zapytania

Primary key dodatkowo z AUTO INCREMENT nigdy nie będzie pusty...

Przy LEFT/RIGHT JOINie może być

Hm podaj jakiś przykład, bo chyba Cie nie rozumiem.

Jemu chyba chodziło o to, że jeżeli w zapytaniu w którym są JOINY pole id może być puste.
Wydaje mi sie, że jest to raczej nie możliwe, jakie zapytanie by nie było id nie zgubi swojej zawartości.

Dodatkowo zastanawiam się, czy przy robieniu stronicowania istnieje opcja, żeby trzeba było robić JOINy... (?)
Edit: Chodzi o zapytanie zliczające (lub pobierające) ilość elementów.