Widziałem w niektórych przykładowych bazach danych ludzie lubią zaokrąglać rozmiary pól do wielokrotności liczby podstawowej 2 (np. Varchar (32) lub varchar (64)) tak, jakby zapewniał im lepszą wydajność lub wykorzystanie przestrzeni. Czy jest jakaś korzyść z tej praktyki? Czy to tylko ludzie są pedantyczni?Czy powinienem zaokrąglić wielkość pola bazy danych do najbliższej wielokrotności numeru podstawowego 2?
Dzięki za Lookin
W MySQL długość powinna zawsze wynosić 255 lub 65 535 (chyba że istnieją powody specyficzne dla danego typu wyboru innej długości). Istnieją dwa różne sposoby przechowywania ciągów znaków. W przypadku długości do 255 długość jest przechowywana w jednym bajcie, a nie w dwóch, co pozwala zapisać bajt pamięci.
W przypadku długości varchar długość jest maksymalną. Wartości są przechowywane na stronie na podstawie ich rzeczywistej długości. Tak więc maksymalna długość nie ma wpływu na przechowywanie czegokolwiek innego, z wyjątkiem 1- lub 2-bajtowych długości (w zależności od tego, czy maksymalna jest < = 255 lub> = 256). (Długość stanowiąca potęgę dwóch - z wyjątkiem 256 - nie ma wpływu na pamięć).
Jeśli chodzi o ustawianie długości jako mocy dwóch. Jestem winny tego przy wielu okazjach. Jest to stary zwyczaj powodowany utrzymywaniem pól wyrównanych na granicach bajtów. Chodziło o to, aby pola były wyrównane na granicach 4- lub 8-bajtowych, ponieważ jest to bardziej optymalne dla procesora (należy użyć języka programowania "C"). Pozwoliło to uniknąć zbędnego miejsca, gdy wartość liczby całkowitej lub zmiennoprzecinkowej wymagała wyrównania 4- lub 8-bajtowego (tak, aby pominięto niektóre bajty) lub niepotrzebnego narzutu, aby skopiować bajty z niewyrównanej przestrzeni do wyrównanej przestrzeni. Oczywiście, jak już zauważyłem, ta logika nie ma podstaw dla baz danych, ponieważ maksymalna długość nie ma wpływu na faktyczne przechowywanie na stronie.
Innym powodem, dla którego nie ma to znaczenia, jest to, że typ varchar przechowuje jeden lub dwa bajty więcej niż długość. Baza danych zajmuje się konwersją z formatu fizycznego na stronie do formatu fizycznego w pamięci. Próba "optymalizacji" tego procesu to znacznie więcej wysiłku, niż jest to warte.
Wierzcie lub nie działa. Nie wierzyłem w to, dopóki sam tego nie zweryfikowałem. Zbudowałem bazę danych z dwoma polami w dwóch tabelach, zindeksowanymi i załadowałem je pełne danych. Jedno pole to VARCHAR (100), a drugie VARCHAR (256).
Podczas kwerendy tabel, pole, które było 256 wykonywane lepiej.
Powodem tego działania jest rozmiar bloku podczas odczytu dysku, pasuje on w górę i dlatego nie odczytuje częściowego bloku na raz.
Czy masz jakieś empiryczne dowody na poparcie tego stwierdzenia? Strony bazy danych są zwykle podobne do 8192 bajtów ... I większość stron powinna być w pamięci RAM i tak –
@Mitch, to było kilka lat temu, więc musiałbym ponownie zbudować przykład, ale być może uda mi się osiągnąć ten przykład tydzień. –
@MitchWheat. . . Byłoby to absolutnie poprawne, ale nie ma to nic wspólnego z mocami 2. Długość 256 razy jest pierwszą długością, w której MySQL używa dwóch bajtów dla długości, a nie 1. –
+1. Długość pola varchar() powinna mieć niewielką różnicę. –
interesujące ..czy znalazłeś namiary w dokumentacji mysql lub czy jest to zgadywana domysły? –
Właściwie wolę wybrać długość varcharu jako moc x równą 2, jest to bardziej intuicyjne dla Dev facetów. : / –