Czy należy unikać MEDIUMINT w MySQL?

InnoDB przechowuje MEDIUMINT jako trzybajtową wartość. Ale kiedy MySQL musi wykonać jakiekolwiek obliczenia, trzy bajty MEDIUMINT są konwertowane na osiem bajtów unsigned long int (zakładam, że obecnie nikt nie uruchamia MySQL na 32 bitach).

Są plusy i minusy, ale rozumiesz, że rozumowanie „jest głupie i wolne, a kod, który to implementuje, jest pełzającym horrorem” nie jest techniczne, prawda?

Powiedziałbym, że MEDIUMINT ma sens, gdy rozmiar danych na dysku jest krytyczny. Tj. gdy tabela ma tak wiele rekordów, że nawet jeden bajt różnicy (4 bajty INT vs 3 bajty MEDIUMINT) wiele znaczy. To raczej rzadki przypadek, ale możliwy.

mach_read_from_3 i mach_read_from_4 - prymitywy używane przez InnoDB do odczytywania liczb z rekordów InnoDB są podobne. Oboje zwracają ulint. Założę się, że nie zauważysz różnicy na żadnym obciążenie pracą.

Wystarczy spojrzeć na kod:

ulint
mach_read_from_3(
/*=============*/
        const byte*     b)      /*!< in: pointer to 3 bytes */
{
        ut_ad(b);
        return( ((ulint)(b[0]) << 16)
                | ((ulint)(b[1]) << 8)
                | (ulint)(b[2])
                );
}

Czy uważasz, że jest znacznie wolniejszy?

ulint
mach_read_from_4(
/*=============*/
        const byte*     b)      /*!< in: pointer to four bytes */
{
        ut_ad(b);
        return( ((ulint)(b[0]) << 24)
                | ((ulint)(b[1]) << 16)
                | ((ulint)(b[2]) << 8)
                | (ulint)(b[3])
                );
}