Dlaczego długość wiersza AVG jest 4 razy większa niż oczekiwano?

Istnieje wiele powodów, dla których średni rozmiar wiersza jest wysoki.

• To jest przybliżenie. (Odkryłem, że jest ona zazwyczaj 2x-3x wysoka.) W jednym ekstremalnym przypadku - jeden wiersz w tabeli - będzie wymagać 16384 bajtów na wiersz. To jest jeden blok InnoDB. Liczba wierszy w tabeli jest szacunkowa . Miejsce na dysku używane dla wierszy jest dokładne, ale patrz poniżej. Średni rozmiar wiersza jest ilorazem tych dwóch.

• Narzut na kolumnę — 1 lub 2 bajty

• Narzut na wiersz - 20-30 bajtów - do obsługi transakcji, znajdowania wierszy w bloku itp.

• Narzut na blok — pewna liczba bajtów na blok 16 KB

• Narzut na thrashowanie w BTree — min to około 1/16 bloku, max to około połowa bloku, średnia to około 30% po wielu usunięciach i/lub losowych wstawkach.

• Narzut na wstępne przydzielanie fragmentów miejsca na dysku (1 MB? 8 MB?)

• Gdy tabela rośnie od dopasowania do jednego bloku, algorytm układu przesuwa się, a procent narzutu tymczasowo wzrasta.

• Usunięte wiersze nie zwracają miejsca do systemu operacyjnego, więc rozmiar pliku pozostaje stały, zwiększając w ten sposób pozorny rozmiar wiersza.

• Jeśli nie masz jawnego PRIMARY KEY lub UNIQUE klucz, który można promować do PK, to jest niedostępne 6-bajtowe pole (na wiersz) dla PK.

• Duży TEXT /BLOB a nawet VARCHAR są przechowywane „niezarejestrowane”. To bardzo komplikuje obliczenia. Zależy to od tego, który z 4 ROW_FORMATs ty używasz. W niektórych przypadkach dla każdej takiej komórki istnieje 20-bajtowy „wskaźnik”.

• FOREIGN KEY ograniczenia nie zwiększają wymaganej przestrzeni, z wyjątkiem tego, że mogą wymusić utworzenie indeksu.

• INDEXes , inny niż PRIMARY KEY nie są uwzględnione w avg_row_length.

• PRIMARY KEY zazwyczaj wiąże się z niewielkim obciążeniem danymi Bdrzewo. Prosta zasada kciuka to 1% kosztów ogólnych (na samej górze kolumny). Ten narzut to węzły niebędące liśćmi BTree.

• Gdy transakcja InnoDB jest zajęta, wszystkie zmodyfikowane wiersze są przechowywane na „liście historii”. Prowadzi to do większego narzutu.

• (Nie do końca powiązane). COMPRESSED InnoDB ma problemy - daje tylko kompresję około 2x, w przeciwieństwie do typowej kompresji tekstu 3x. Kosztuje trochę pamięci RAM ze względu na konieczność posiadania jednocześnie skompresowanych i nieskompresowanych danych w puli buforów (przynajmniej dla niektórych bloków).

SHOW TABLE STATUS i pobieranie z information_schema.TABLES daje te same dane. Są sposoby na zdobycie niektórych wgląd w głębokość B+drzewa dla danych i dla każdej tabeli.