sql >> Databasteknik >  >> RDS >> Mysql

Bör MEDIUMINT undvikas i MySQL?

InnoDB lagrar MEDIUMINT som ett värde på tre byte. Men när MySQL måste göra någon beräkning konverteras de tre byten MEDIUMINT till åtta byte utan tecken lång int (jag antar att ingen kör MySQL på 32 bitar nuförtiden).

Det finns för- och nackdelar, men du förstår att "det är dumt, och det är långsamt, och koden som implementerar det är en krypande skräck"-resonemang inte är tekniskt, eller hur?

Jag skulle säga att MEDIUMINT är vettigt när datastorleken på disken är kritisk. d.v.s. när en tabell har så många poster att även en byte skillnad (4 byte INT vs 3 byte MEDIUMINT) betyder mycket. Det är ganska sällsynt, men möjligt.

mach_read_from_3 och mach_read_from_4 - primitiver som InnoDB använder för att läsa siffror från InnoDB-poster är liknande. De återvänder båda ulint. Jag slår vad om att du inte kommer att märka någon skillnad på någon arbetsbelastning.

Ta bara en titt på koden:

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])
                );
}

Tycker du att det går mycket långsammare än så här?

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])
                );
}


  1. INSERT-satsen kom i konflikt med FOREIGN KEY-begränsningen - SQL Server

  2. Vad är Oracle SQL &PL/SQL? Allt en nybörjare behöver veta

  3. utf8_bin kontra utf_unicode_ci

  4. SQL Server:Hur får man främmande nyckelreferens från information_schema?