MySQL
Datatyper

Implicit / automatisk gjutning

select '123' * 2;

För att göra multiplikationen med 2 konverterar MySQL automatiskt strängen 123 till ett nummer.

Returvärde:

246

Konverteringen till ett nummer startar från vänster till höger. Om omvandlingen inte är möjlig är resultatet 0

select '123ABC' * 2

Returvärde:

246

select 'ABC123' * 2

Returvärde:

0

VARCHAR (255) - eller inte

Föreslagen max len

Först kommer jag att nämna några vanliga strängar som alltid är hex, eller på annat sätt begränsade till ASCII. För dessa bör du ange CHARACTER SET ascii ( latin1 är ok) så att det inte slösar utrymme:

UUID CHAR(36) CHARACTER SET ascii -- or pack into BINARY(16)
country_code CHAR(2) CHARACTER SET ascii
ip_address CHAR(39) CHARACTER SET ascii -- or pack into BINARY(16)
phone VARCHAR(20) CHARACTER SET ascii -- probably enough to handle extension
postal_code VARCHAR(20) CHARACTER SET ascii -- (not 'zip_code') (don't know the max

city VARCHAR(100) -- This Russian town needs 91:
    Poselok Uchebnogo Khozyaystva Srednego Professionalno-Tekhnicheskoye Uchilishche Nomer Odin
country VARCHAR(50) -- probably enough
name VARCHAR(64) -- probably adequate; more than some government agencies allow

Varför inte bara 255? Det finns två skäl att undvika vanligt att använda (255) för allt.

• När ett komplex SELECT behöver skapa en tillfällig tabell (för en undersökning, UNION , GROUP BY , etc.) är det föredragna valet att använda MEMORY motorn, som sätter data i RAM. Men VARCHARs förvandlas till CHAR i processen. Detta gör att VARCHAR(255) CHARACTER SET utf8mb4 tar 1020 byte. Det kan leda till att man behöver spilla till disken, vilket är långsammare.
• I vissa situationer kommer InnoDB att titta på den potentiella storleken på kolumnerna i en tabell och bestämma att den blir för stor och avbryter en CREATE TABLE .

VARCHAR kontra TEXT

Tips om användning av *TEXT , CHAR och VARCHAR , plus några bästa metoder:

• TINYTEXT aldrig TINYTEXT .
• CHAR nästan aldrig CHAR - det är fast längd; varje tecken är den maximala längden för CHARACTER SET (t.ex. 4 byte / tecken för utf8mb4).
• CHAR , använd CHARACTER SET ascii om du inte vet något annat.
• VARCHAR(n) trunkeras vid n tecken ; TEXT kommer att avkortas vid ett antal byte . (Men vill du ha trunkering?)
• *TEXT kan bromsa komplexa SELECTs grund av hur temp-tabeller hanteras.

INT som AUTO_INCREMENT

Alla storlekar på INT kan användas för AUTO_INCREMENT . UNSIGNED är alltid lämpligt.

Tänk på att vissa operationer "bränner" AUTO_INCREMENT id. Detta kan leda till ett oväntat gap. Exempel: INSERT IGNORE och REPLACE . De kan förflytta en id innan de inser att det inte kommer att behövas. Detta förväntas beteende och genom design i InnoDB-motorn och bör inte avskräcka deras användning.

Övriga

Det finns redan en separat post för "FLOAT, DUBBLE and DECIMAL" och "ENUM". En enda sida om datatyper är troligtvis olämplig - jag föreslår att "Fälttyper" (eller ska det kallas "Datatyper"?) Är en översikt och dela sedan in i dessa ämnesidor:

• INTs
• FLOAT, DUBBELT och DECIMAL
• Strängar (CHARs, TEXT, etc)
• BINARY och BLOB
• DATETIME, TIMESTAMP och vänner
• ENUM och SET
• Rumsliga data
• JSON-typ (MySQL 5.7.8+)
• Hur man representerar pengar och andra vanliga ”typer” som behöver skogsskydd i befintliga datatyper

I förekommande fall bör varje ämnesida, förutom syntax och exempel, innehålla:

• Överväganden vid ALTERING
• Storlek (byte)
• Kontrast med icke-MySQL-motorer (låg prioritet)
• Överväganden när du använder datatypen i en PRIMÄRKNAPP eller sekundärnyckel
• andra bästa praxis
• andra resultatfrågor

(Jag antar att detta "exempel" kommer att förstöra sig när mina förslag har varit nöjda eller veto.)

Introduktion (numerisk)

MySQL erbjuder ett antal olika numeriska typer. Dessa kan delas upp i

Heltalstyper

Minimalt osignerat värde är alltid 0.

Fastpunkttyper

MySQL: s DECIMAL och NUMERIC typer lagrar exakta numeriska datavärden. Det rekommenderas att använda dessa typer för att bevara exakt precision, till exempel för pengar.

Decimal

Dessa värden lagras i binärt format. I en kolumndeklaration ska precisionen och skalan anges

Precision representerar antalet betydande siffror som lagras för värden.

Skala representerar antalet siffror som lagras efter decimalen

salary DECIMAL(5,2)

5 representerar precision och 2 representerar scale . I det här exemplet är värdena som kan lagras i denna kolumn -999.99 to 999.99

Om skalparametern utelämnas är standardvärdet 0

Denna datatyp kan lagra upp till 65 siffror.

Antalet byte som tas av DECIMAL(M,N) är ungefär M/2 .

Flytande punkttyper

FLOAT och DOUBLE representerar ungefärliga datatyper.

REAL är en synonym för FLOAT . DOUBLE PRECISION är en synonym för DOUBLE .

Även MySQL tillåter också (M, D) kval, inte använda den. (M, D) betyder att värden kan lagras med upp till M-siffror, där D kan vara efter decimal. Siffrorna rundas två gånger eller trunkeras; detta kommer att orsaka mer problem än nytta.

Eftersom flytpunktsvärden är ungefärliga och inte lagras som exakta värden, kan försök att behandla dem som exakta i jämförelser leda till problem. Observera särskilt att ett FLOAT värde sällan är lika med ett DOUBLE värde.

Typ av bitvärde

BIT typen är användbar för att lagra bitfältvärden. BIT(M) tillåter lagring av upp till M-bitvärden där M är i intervallet 1 to 64

Du kan också ange värden med bit value .

b'111'      -> 7
b'10000000' -> 128

Ibland är det praktiskt att använda 'shift' för att konstruera ett enbitsvärde, till exempel (1 << 7) för 128.

Den maximala kombinerade storleken på alla BIT-kolumner i en NDB tabell är 4096.

CHAR (n)

CHAR(n) är en sträng med en fast längd på n tecken . Om det är CHARACTER SET utf8mb4 , betyder det att det upptar exakt 4*n byte , oavsett vilken text som finns i den.

De flesta fall som används för CHAR(n) involverar strängar som innehåller engelska tecken, därför bör CHARACTER SET ascii . ( latin1 kommer att göra lika bra.)

country_code CHAR(2) CHARACTER SET ascii,
postal_code  CHAR(6) CHARACTER SET ascii,
uuid    CHAR(39) CHARACTER SET ascii,  -- more discussion elsewhere

DATE, DATETIME, TIMESTAMP, YEAR och TIME

DATE DATE innehåller datum men ingen tidskomponent. Dess format är 'YYYY-MM-DD' med ett intervall '1000-01-01' till '9999-12-31'.

DATETIME typen inkluderar tiden med ett format "YYYY-MM-DD HH: MM: SS". Det har ett intervall från '1000-01-01 00:00:00' till '9999-12-31 23:59:59'.

TIMESTAMP typen är en heltalstyp som innehåller datum och tid med ett effektivt intervall från '1970-01-01 00:00:01' UTC till '2038-01-19 03:14:07' UTC.

YEAR typen representerar ett år och har ett intervall från 1901 till 2155.

TIME typen representerar en tid med ett format av 'HH: MM: SS' och har ett intervall från '-838: 59: 59' till '838: 59: 59'.

Lagringskrav:

|-----------|--------------------|----------------------------------------|
| Data Type | Before MySQL 5.6.4 | as of MySQL 5.6.4                      |
|-----------|--------------------|----------------------------------------|
| YEAR      |      1 byte        |  1 byte                                |
| DATE      |      3 bytes       |  3 bytes                               |
| TIME      |      3 bytes       |  3 bytes + fractional seconds storage  |
| DATETIME  |      8 bytes       |  5 bytes + fractional seconds storage  |
| TIMESTAMP |      4 bytes       |  4 bytes + fractional seconds storage  |
|-----------|--------------------|----------------------------------------|

Fraktionssekunder (från version 5.6.4):

|------------------------------|------------------|
| Fractional Seconds Precision | Storage Required |
|------------------------------|------------------|
|              0               |      0 bytes     |
|              1,2             |      1 byte      |
|              3,4             |      2 byte      |
|              5,6             |      3 byte      |
|------------------------------|------------------|

Se MySQL manualsidor DATE, DATETIME och tidsstämpel typer , Datatyp Lagring Krav och Fractional sekunder i tidsvärden .