Dlaczego wszystkie tabele MySQL InnoDB są pofragmentowane?

10

Z jakiegoś powodu wszystkie tabele InnoDB na moim serwerze MySQL są wyświetlane jako pofragmentowane, gdy uruchamiam mysqltuner. Serwer zainstalowałem dopiero kilka godzin temu (na OSX Lion) i ma w nim mnóstwo świeżych danych zaimportowanych z plików wsadowych.

Próbowałem przekonwertować wszystkie tabele w jednej bazie danych na MYISAM i na pewno zmniejszyła się liczba pofragmentowanych tabel. Dziwne jednak, gdy tylko przekonwertowałem te tabele z powrotem na InnoDB, fragmentaryczna liczba stolików ponownie wzrosła. Jest to sprzeczne z moimi dotychczasowymi badaniami, które sugerują, że bieganie ALTER TABLE table_name ENGINE=INNODB;powinno naprawić fragmentację.

Po trochę Googlingu pobiegłem:

SELECT table_schema, table_name, data_free/1024/1024 AS data_free_MB 
FROM information_schema.tables
WHERE engine LIKE 'InnoDB' AND data_free > 0

Który rzekomo zawiera listę wszystkich pofragmentowanych tabel (faktycznie zwraca taką samą liczbę wyników jak wyniki mysqltuner dla liczby pofragmentowanych tabel). Każdy pojedynczy wpis ma dokładnie ten sam numer w data_free_MBkolumnie (obecnie 7.00000000).

Czy to rzeczywiście prawdziwy problem, czy coś, co mysqltuner robi źle? Jeśli to problem, jak to naprawić?

EDYTOWAĆ

Coraz bardziej podejrzewam, że jestem idiotą i że fragmentacja 7 MB dotyczy całego pliku, a nie każdej tabeli. Czy ktoś może potwierdzić, czy tak by było?

Clive
źródło
Czy naprawdę uważasz, że 7 wolnych MB to problem?
David Schwartz,
@DavidSchwartz Nie mam pojęcia, dlatego zapytałem;) Istnieją 2314 stołów, każdy z 7 MB wolnego, i nie wiem, co to znaczy. Nie jestem pewien, dlaczego mysqltuner pokazałby mi tę liczbę, gdyby nie był to potencjalny powód do niepokoju. Miałem nadzieję, że ktoś tutaj może mi powiedzieć, jak zaniepokojony jest nadawanie liczb i co mogę zrobić, aby złagodzić problem, ponieważ „standardowe” metody nie działają
Clive
Migracja tego pytania zgodnie z żądaniem użytkownika w postaci flagi.
Daniel Beck
Większość szczegółów, które pokazuje mysqltuner, ma jedynie charakter informacyjny. Nie wszystko jest problemem. Jeśli jest to problem, wyraźnie to powie. Czy wskazano to jako problem?
John Gardeniers,
@JohnGardeniers Wierzę, że tak, wiadomość brzmi: [!!] Total fragmented tables: 2314co, jestem pewien, wskazuje na problem (z podwójnymi czerwonymi wykrzyknikami)
Clive

Odpowiedzi:

5

Zgodnie z powyższymi komentarzami nie wszystkie dane wyjściowe z narzędzia sqltuner wskazują na błędy. O ile skrypt nie mówi wyraźnie, że jest to problem, zwykle w następnym wierszu, a następnie sugestie dotyczące naprawy, to jest to tylko element informacyjny.

John Gardeniers
źródło
3

Po włączeniu innodb_file_per_table wszystko, co zrobiłeś, to skonfigurowanie protokołu, aby nowe tabele InnoDB były tworzone w .ibdpliku zewnętrznym . Wszystkie tabele InnoDB, które wcześniej utworzyłeś, są nadal osadzone w ibdata1.

Przy wyłączonym pliku innodb_file_per_table przy każdym uruchomieniu

ALTER TABLE table_name ENGINE=INNODB;

wszystko, co robi, to dołącza dane i strony indeksu tabeli do ibdata1. To sprawi, że tabela będzie istnieć na sąsiadujących stronach i usunie fragmentację. Wadą jest to, że ibdata1 rośnie szybko.

REKOMENDACJE

Musisz wyeksportować wszystkie dane, usunąć ibdata1, ib_logfile0, ib_logfile1 i załadować ponownie.

Napisałem, jak i dlaczego to zrobić

AKTUALIZACJA 2012-08-15 12:05 EDT

Możesz zajrzeć do samego skryptu mysqltuner.pl. IMHO Myślę, że używa starej formuły do ​​pomiaru fragmentacji. Upewnij się, że masz najnowszą wersję mysqltuner.

Jeśli chodzi o pomiar fragmentacji tabel InnoDB przechowywanych zewnętrznie, napisałem o tym post 11 kwietnia 2012 r. (Zobacz aktualizację na dole z 19 kwietnia 2012 r.)

RolandoMySQLDBA
źródło
1
Ach, ok, dzięki temu wszystko nabrało większego sensu. W końcu wyeksportowałem dane, całkowicie wyczyściłem MySQL, a następnie ponownie instalowałem (ale dodawałem innodb_file_per_tabledo pliku conf przed uruchomieniem serwera i ponownym importowaniem). Wcześniej otrzymywałem różnego rodzaju błędy InnoDB (naprawdę złe rodzaje ... te, które oznaczały, że musiałem biegać z innodb_force_recoverypoziomem 6 tylko po to, aby wydostać dane!), I wszelkiego rodzaju „data pliku dziennika jest w przyszłość!' błędy. Wygląda na to, że już się skończyły, ale wciąż mam sporo rozdrobnionych stołów. Po prostu będę miał na to oko, jeszcze raz dziękuję za wkład
Clive
niesamowite! jest to bardzo pouczające. Dzięki @RolandoMySQLDBA!
Sudhi,