Prawidłowe polecenie w MySQL do naprawy uszkodzonej lub niespójnej tabeli to `REPAIR TABLE`. Jest to oficjalna, udokumentowana komenda SQL w MySQL, przeznaczona właśnie do diagnozowania i naprawiania problemów z tabelami, głównie w silniku MyISAM, a w ograniczonym zakresie także w innych silnikach. W praktyce używa się jej np. gdy tabela nagle „znika” z widoku aplikacji, pojawiają się błędy typu „table is marked as crashed and should be repaired” albo gdy phpMyAdmin zgłasza problemy z integralnością danych na poziomie pliku tabeli. Typowe użycie wygląda tak: `REPAIR TABLE nazwa_tabeli;` albo z dodatkowymi opcjami, np. `REPAIR TABLE nazwa_tabeli QUICK;` czy `REPAIR TABLE nazwa_tabeli EXTENDED;`, w zależności od tego, jak głęboka ma być analiza struktury. Z mojego doświadczenia warto pamiętać, że `REPAIR TABLE` działa na poziomie fizycznych plików tabeli (szczególnie w MyISAM), więc dobrze jest wcześniej mieć kopię zapasową, bo przy poważnych uszkodzeniach część rekordów może zostać utracona przy próbie naprawy. W nowoczesnych projektach, gdzie dominuje InnoDB, częściej polega się na mechanizmach automatycznego odzyskiwania, logach transakcyjnych i backupach, ale znajomość `REPAIR TABLE` nadal jest przydatna przy pracy ze starszymi systemami albo przy mieszanych środowiskach. Dobrą praktyką administracyjną jest też poprzedzenie naprawy poleceniem `CHECK TABLE`, żeby zobaczyć, co dokładnie jest nie tak. Podsumowując: `REPAIR TABLE` to narzędzie serwisowe, a nie coś, czego używa się codziennie w kodzie aplikacji, ale w sytuacjach awaryjnych potrafi uratować bazę.
W MySQL tylko jedna z podanych komend jest rzeczywistym, udokumentowanym poleceniem służącym do naprawy struktury tabeli i jest to `REPAIR TABLE`. Pozostałe propozycje wynikają najczęściej z mieszania intuicji językowej z faktyczną składnią SQL. Wiele osób myśli na zasadzie „chcę coś naprawić, to wpiszę FIX”, ale w standardowym SQL i w MySQL nie istnieje polecenie `FIX TABLE`. To zbitka słowna, która brzmi sensownie po angielsku, ale nie ma żadnego odzwierciedlenia w parserze MySQL. W praktyce wpisanie takiej komendy skończy się zwykłym błędem składniowym i żadna tabela nie zostanie ani naprawiona, ani nawet dotknięta. Podobny problem dotyczy `CHANGE TABLE`. W MySQL mamy `ALTER TABLE`, które służy do zmiany struktury tabeli (dodawanie kolumn, zmiana typu, indeksów itd.), natomiast komenda `CHANGE TABLE` po prostu nie istnieje. Jest tu mylące to, że w ramach `ALTER TABLE` jest podpolecenie `CHANGE` dla kolumn, np. `ALTER TABLE t CHANGE stara_kolumna nowa_kolumna INT;`, ale to zupełnie inny poziom – zmiana definicji kolumny, a nie naprawa uszkodzonej tabeli. Najbardziej zdradliwe jest natomiast `UPDATE TABLE`. W SQL istnieje `UPDATE`, ale działa ono na rekordach, a nie na samej tabeli jako strukturze. Poprawna składnia to `UPDATE nazwa_tabeli SET kolumna=wartosc WHERE warunek;`. To polecenie modyfikuje dane w wierszach, nie reperuje indeksów, nagłówków plików czy struktury fizycznej. Typowy błąd myślowy polega na tym, że ktoś utożsamia „naprawę” z „zmianą danych”, podczas gdy problemy, które rozwiązuje `REPAIR TABLE`, dotyczą integralności na poziomie pliku tabeli, a nie logiki rekordów. Z punktu widzenia dobrych praktyk administracyjnych warto rozróżniać: `UPDATE` do modyfikacji zawartości, `ALTER TABLE` do modyfikacji schematu i `REPAIR TABLE` (plus `CHECK TABLE`) do działań serwisowych przy uszkodzeniach. Mylenie tych komend może prowadzić do sytuacji, gdzie administrator próbuje „naprawiać” bazę błędnymi poleceniami, a prawdziwy problem dalej pozostaje nierozwiązany.