Domyślnie pola INT w bazie mają długość maksimum 11 cyferek. Odpowiada mi to i zazwyczaj przy tworzeniu bazy nie zmieniam tej "propozycji", także przy identyfikatorach. Niestety mechanizm auto inkrementacji nie działa zgodnie z moimi oczekiwaniami. Może to stwierdzenie brzmi trochę jakbym to ja miał problem, ale myślę, że wiele osób się z tym boryka.
Problem właściwie składa się z ...dwóch problemów , a ujawnia się przy kasowaniu danych:
1. Przy kasowaniu danych z samego końca, licznik auto_inkrementa nie zmniejsza się, przez co zostaje dziura w identyfikatorach.
2. Przy kasowaniu danych ze środka również powstają dziury, a niestety baza nie cofa identyfikatorów.
Co do drugiego punktu to może trochę przesadziłem, bo silnik musiałby myśleć za mnie, aby cofnąć identyfikatory we wszystkich obcych kluczach powiązanych z bazą, w której dokonywałem zmian.

Wszystko to sprowadza się do jednego problemu: Fakt, że trochę potrwa, zanim bazę zapełni 10.000.000.000 pozycji, ale jeśli tak się stanie, to na pewno będzie sporo wolnych do wykorzystania.
Zastanawia mnie, czy w ogóle jest sens martwienia się o to, czy może to olać?
A jeżeli warto pracować z tymi identyfikatorami, to czy jest jakiś efektywny sposób na wbijanie nowych danych, pod wolnymi numerami?

Czytać: nie zajrzalem do manuala.

Rozwiazanie takie bylo by skomplikowane. Albo by zajmowalo mase pamieci (pamietanie ktore liczby sa wolne), albo powolne (skanowanie tabeli i szukanie pierwszego wolnego miejsca).

Zawsze mozesz uzyc BIGINT'a. Co ci da 4mld wiecej liczb.

A tak poza tym, w autoincrement właśnie o to chodzi, żeby dany index nie został ponownie wykorzystany. W przypadku usunięcia wiersza z jakimś id, w innej tabeli te id może pozostać nie usunięte. Select da w tym polu NULL. A jeśli przepiszesz id z autoincrement to pole będzie odnosiło do innej wartości niż poprzednio.

Żeby mogło to działać należałoby przepisać też wszystkie odniesienia do danego id. A wyobrażasz sobie ile to roboty?

Weźmy np tabele A z 1 mln wierszy. Tabele B, C, D, E po 3 mln wierszy. W każdej od B do E mamy pole z id z tabeli A. Teraz usuwamy w tabeli A drugi wiersz. Do przepisania mamy 999 998 wierszy. Teraz wszystkie odnośniki do tych id w powiązanych tabelach przestają być aktualne, zatem w tabelach B-E trzeba przepisać odnośniki 4 tabele po 3 mln wierszy = 12 mln operacji. Dołożyć do tego mechanizm wyszukania które pola z czego na co zmienić robi się na prawdę obciążające zadanie.

Nie, gdyż to nie ma sensu, jak napisali przedmówcy. Tak BTW, masz unsigned przy deklaracji pola?