Decimal VS Int w MySQL?

Question

Czy występują różnice w wydajności między typem decimal(10,0) unsigned a typem int(10) unsigned?

Answer 1

Może to zależeć od używanej wersji MySQL. Zobacz here.

Przed wersją MySQL 5.0.3 typ DECIMAL był zapisywany jako ciąg znaków i zwykle był wolniejszy. Jednak, ponieważ MySQL 5.0.3 typ DECIMAL jest przechowywany w formacie binarnym, więc z wielkością powyższego DECIMAL, może nie być dużej różnicy w wydajności.

Głównym problemem z wydajnością byłaby ilość miejsca zajmowana przez różne typy (z DECIMAL jest wolniejsza). Z MySQL 5.0.3+ wydaje się to mniejszym problemem, jednak jeśli wykonasz obliczenia numeryczne na wartościach jako część zapytania, może wystąpić różnica w wydajności. To może być warte testowania, ponieważ nie ma wskazań w dokumentacji, którą widzę.

Edit: W odniesieniu do int(10) unsigned, wziąłem to za dobrą monetę, jak tylko będąc int 4 bajtów. Jednak ma on maksymalną wartość 4294967295, która ściśle nie zapewnia takiego samego zakresu liczb jak DECIMAL(10,0) unsigned.

Jak zauważyła firma @Unreason, konieczne jest użycie bigint, aby pokryć pełen zakres 10-cyfrowych numerów, przesuwając ten rozmiar do 8 bajtów.

Powszechnym błędem jest to, że podczas określania typów kolumn numerycznych w MySQL ludzie często uważają, że liczba w nawiasach ma wpływ na rozmiar przechowywanej liczby. Tak nie jest. Zakres liczb zależy wyłącznie od typu kolumny i od tego, czy jest podpisany czy niepodpisany. Liczba w nawiasach służy do wyświetlania wyników i nie ma wpływu na wartości przechowywane w kolumnie. Nie będzie to miało wpływu na wyświetlanie wyników, chyba że podasz również opcję ZEROFILL w kolumnie.

Answer 2

Wątpię, aby taka różnica mogła w ogóle być związana z wydajnością.
Większość problemów związanych z wydajnością wiąże się z odpowiednim projektem bazy danych i planem indeksowania, a dostrojenie serwera/sprzętu do następnego poziomu.

Answer 3

Według danych mysql storage Twój dziesiętny będzie wymagać

dziesiętnego (10,0): 4 bajty do 9 cyfr i 1 bajt dla pozostałych 10 cyfry, a więc w całkowitych pięciu bajtów (zakładając moje czytanie dokumentacji jest poprawne).

INT (10): will need BIGINT, który ma 8 bajtów.

Różnica polega na tym, że rozkład dziesiętny jest spakowany, a niektóre operacje na takim typie danych mogą być wolniejsze niż na zwykłych typach INT, które są odwzorowywane bezpośrednio na liczby reprezentowane przez komputer.

Nadal chciałbym zrobić własne testy, aby potwierdzić powyższe rozumowanie.

EDYCJA: Zauważyłem, że nie wyjaśniłem tego w oczywisty sposób - zakładając, że powyższa logika brzmi, różnica w wymaganej wielkości to 60% więcej miejsca dla wariantu BIGINT.

Nie przekłada się to jednak bezpośrednio na kary, ponieważ dane zwykle nie są zapisywane bajt po bajcie.W przypadku wyborów/aktualizacji wielu wierszy powinieneś zobaczyć utratę/zysk wydajności, ale w przypadku wybrania/aktualizacji małej liczby wierszy system plików pobierze bloki z dysków, które normalnie pobierają/zapisują wiele kolumn .
Wielkość (i szybkość) indeksów może być bardziej bezpośrednio wpłynęła. Jednak pytanie, w jaki sposób opakowanie wpływa na różne operacje, nadal pozostaje otwarte.

Answer 4

Zgodnie z tym podobne pytanie, tak, potencjalnie istnieje duża wydajność hit z powodu różnicy w sposobie DECIMAL i INT są traktowane i wkręcona w CPU podczas wykonywania obliczeń.

Patrz: Is there a performance hit using decimal data types (MySQL/Postgres)