En introduktion till MySQL-datatyper

Introduktion

En av de primära egenskaperna hos relationsdatabaser i allmänhet är förmågan att definiera scheman eller tabellstrukturer som exakt anger formatet på de data som de kommer att innehålla. Detta görs genom att föreskriva kolumnerna som dessa strukturer innehåller tillsammans med deras datatyp och eventuella begränsningar.

Datatyper anger ett allmänt mönster för den data de accepterar och lagrar. Värden måste följa de krav som de beskriver för att accepteras av MySQL. Även om det är möjligt att definiera anpassade krav, tillhandahåller datatyper de grundläggande byggstenarna som gör att MySQL kan validera indata och arbeta med data med hjälp av lämpliga operationer.

MySQL innehåller ett brett utbud av datatyper som används för att märka och validera att värden överensstämmer med lämpliga typer. I den här guiden kommer vi att diskutera de vanligaste datatyperna som finns tillgängliga i MySQL, de olika in- och utdataformat de använder och hur man konfigurerar olika fält för att möta dina applikationers behov.

Vilka är datatyperna i MySQL?

Innan vi går in i detalj, låt oss ta en bred bild av vilka datatyper MySQL tillhandahåller.

MySQL stöder ett rimligt utbud av datatyper som lämpar sig för olika typer av enkla och komplexa data. Dessa inkluderar:

• TINYINT
• SMALLINT
• MEDIUMINT
• INT
• BIGINT
• DECIMAL
• NUMERIC
• FLOAT
• DOUBLE
• BIT
• DATE
• DATETIME
• TIMESTAMP
• TIME
• YEAR
• CHAR
• VARCHAR
• BINARY
• VARBINARY
• BLOB
• TEXT
• ENUM
• SET
• GEOMETRY
• POINT
• LINESTRING
• POLYGON
• MULTIPOINT
• MULTILINESTRING
• MULTIPOLYGON
• GEOMETRYCOLLECTION
• JSON

Vi kommer att täcka de vanligaste av dessa mer ingående i den här guiden.

Komma igång med MySQL-datatyper

När du kommer igång med typer är det viktigt att komma ihåg att typer ensamma inte alltid är en komplett lösning för datavalidering, utan en komponent. Andra databasverktyg, som begränsningar, har också en roll att spela för att definiera korrekthet. Ändå är datatyper ofta den första försvarslinjen mot ogiltiga data.

I många fall är de allmänna typerna som tillhandahålls av MySQL lämpliga för den typ av data du kommer att lagra. Du kan till exempel lagra koordinaterna för en geometrisk punkt i två olika talkolumner, men den angivna point typen är specialbyggd för att lagra och validera exakt denna typ av information. När du väljer typer, kontrollera att du använder den mest specifika typen som gäller för ditt användningsfall.

Siffror och numeriska värden

MySQL innehåller en rad numeriska datatyper som är lämpliga för olika scenarier. Den lämpliga typen beror på den exakta karaktären hos de värden du planerar att lagra samt dina precisionskrav.

Heltal

heltal datatyp är en kategori av typer som används för att lagra tal utan bråktal eller decimaler. Dessa kan vara antingen positiva eller negativa värden, och olika heltalstyper kan lagra olika intervall av tal. Heltalstyper med mindre intervall av acceptabla värden tar mindre plats än de med bredare intervall.

Den grundläggande listan över heltalstyper inkluderar följande:

Typerna ovan är begränsade av deras giltiga intervall. Alla värden utanför intervallet kommer att resultera i ett fel.

Utöver de ovan nämnda typerna känner MySQL även igen ett alias som heter SERIAL . Markera en kolumn som SERIAL ger den dessa egenskaper:BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE . Detta används som en förkortning för vanliga primärnyckelkolumnegenskaper. Kolumnen kommer automatiskt att tilldela ett nytt unikt värde när en post läggs till.

Fast punkt

Typer av fasta punkter används för att kontrollera mängden precision eller specificitet möjlig för ett tal med decimaler. I MySQL kan detta kontrolleras genom att manipulera två faktorer:precision och skala.

Precision är det maximala antalet totala siffror som ett nummer kan ha. Däremot skala är antalet siffror till höger om decimalkomma. Genom att manipulera dessa siffror kan du kontrollera hur stora bråkdelar och icke-bråkdelar av ett tal tillåts vara.

Dessa två argument används för att styra godtycklig precision med numeric eller decimal datatyper (dessa två typer är synonyma i MySQL). Den numeric typ tar noll till två argument.

Utan argument definieras kolumnen som att ha en precision på 10 och en skala på 0. Det betyder att kolumnen kan innehålla upp till 10 siffror, men ingen av dessa kan vara efter decimalkomma:

NUMERIC
 

När ett enda argument tillhandahålls tolkas det som precisionen för kolumnen med skalan inställd på 0. Detta gör att du effektivt kan ange det maximala antalet siffror i ett heltalsliknande tal (inga bråk- eller decimalkomponenter). Om du till exempel behöver ett 5-siffrigt heltal kan du ange:

NUMERIC(5)
 

Ange precision följt av skala när du konfigurerar en kolumn med båda kontrollerna. MySQL kommer att runda av decimalkomponenten för varje inmatning till rätt antal siffror med hjälp av skalantalet. MySQL kommer att använda precisionen och skalan för att bestämma hur många siffror som är tillåtna på vänster sida av decimalkomman. Om en post överskrider det tillåtna antalet siffror kommer MySQL att ge ett felmeddelande.

Till exempel kan vi ange en kolumn med en total precision på 5 och en skala på 2:

NUMERIC(5, 2)
 

Den här kolumnen skulle ha följande beteende:

Flytpunkt

Flyttal är ett annat sätt att uttrycka decimaltal, men utan exakt, konsekvent precision. Istället har flyttalstyper bara ett koncept med maximal precision som ofta är relaterat till hårdvarans arkitektur och plattform.

Till exempel, för att begränsa en flyttalskolumn till 8 siffrors precision, kan du använda FLOAT typ, som lagrar resultat med 4 byte med allt från 0 till 23 siffror med precision:

FLOAT(8)
 

På samma sätt är DOUBLE typ använder 8 byte för att lagra data och kan använda precisioner på 24 till 53 siffror.

På grund av dessa designval kan flyttalsnummer fungera effektivt med tal med ett stort antal decimaler, men inte alltid exakt. Den interna representationen av siffror kan orsaka små skillnader mellan indata och utdata. Detta kan orsaka oväntat beteende när man jämför värden, gör flyttal-matematik eller utför operationer som kräver exakta värden.

Flytpunkt vs numerisk

Båda flyttalstalen tillhandahålls av typer som FLOAT och DOUBLE och fixpunktsnummer som tillhandahålls av NUMERIC eller DECIMAL typer kan användas för att lagra decimalvärden. Hur vet du vilken du ska använda?

Den allmänna regeln är att om du behöver exakthet i dina beräkningar, NUMERIC typ är alltid det bättre valet. NUMERIC typ kommer att lagra värden exakt som de tillhandahålls, vilket innebär att resultaten är helt förutsägbara när man hämtar eller beräknar över värden. NUMERIC typ kallas godtycklig precision eftersom du anger mängden precision som typen kräver och den kommer att lagra den exakta mängden siffror i fältet.

Däremot typer som FLOAT och DOUBLE är olika precisionstyper. Mängden precision de bibehåller beror på ingångsvärdet. När de når slutet av sin tillåtna precisionsnivå kan de runda av de återstående siffrorna, vilket leder till skillnader mellan de inlämnade och hämtade värdena.

Så när skulle du använda olika precisionstyper? Varierande precisionstyper som FLOAT och DOUBLE är väl lämpade för scenarier där exakta värden inte är nödvändiga (till exempel om de ändå ska avrundas) och när hastigheten är mycket värdefull. Variabel precision ger generellt prestandafördelar jämfört med NUMERIC typ.

Strängtyper

MySQL:s teckentyper och strängtyper kan placeras i två kategorier:fast längd och variabel längd . Valet mellan dessa två påverkar hur MySQL allokerar utrymme för varje värde och hur det validerar indata.

Den enklaste teckenbaserade datatypen i MySQL är char typ. Utan argument, char typ accepterar ett enstaka tecken som indata:

CHAR
 

När ett positivt heltal anges i deklarationen visas char kolumnen lagrar en teckensträng med fast längd som är lika med antalet angivna tecken:

CHAR(10)
 

Om en sträng är försedd med färre tecken kommer tomma mellanslag att läggas till för att fylla på längden:

Om en sträng ges med fler än det tillåtna antalet tecken, kommer MySQL att visa ett fel. Som ett undantag från denna regel, om de överfulla tecknen alla är mellanslag, kommer MySQL helt enkelt att trunkera de överflödiga mellanrummen för att passa fältet.

Alternativet till tecken med fast längd är fält med variabel längd. För detta tillhandahåller MySQL varchar typ. varchar typ lagrar tecken utan fast storlek. Till skillnad från char , varchar kan inte användas utan att ange det maximala antalet tecken som ska lagras.

Genom att definiera en varchar med ett positivt heltal kan du ställa in en maximal stränglängd:

VARCHAR(10)
 

Detta skiljer sig från att använda char skriv med ett heltal i den varchar kommer inte att fylla ut värdet om inmatningen inte uppfyller den maximala fältlängden:

Om strängen är större än den maximala längden kommer MySQL att ge ett fel. Samma trunkeringsbeteende som finns i char fält förekommer här:om de överfulla tecknen är mellanslag, kommer de att trunkeras för att passa inom den maximala teckenlängden.

MySQL stöder även binary och varbinary datatyper. Dessa fungerar på liknande sätt som char och varchar typer, men lagra binära strängar snarare än teckensträngar. Detta har konsekvenser för hur de lagras och opereras (för saker som jämförelser, sortering etc.).

För binary och varbinary typer, det heltal som anges när kolumntypen definieras representerar antalet byte istället för antalet tecken.

Två andra datatyper som MySQL tillhandahåller för strängar och teckenlagring är blob och text . Dessa typer fungerar på samma sätt som varchar och varbinary typer respektive och är avsedda för förvaring av stora föremål. De fungerar för det mesta på samma sätt som sina motsvarigheter, men har några skillnader som att inte börja kunna ha standardvärden och att kräva en prefixlängd när du skapar ett index.

Booleans

MySQL har faktiskt inte en ursprunglig boolesk typ för att representera sanna och falska värden.

MySQL känner igen typerna BOOL eller BOOLEAN i ett försök för kompatibilitet med andra databassystem. Dess interna implementering använder dock en TINYINT(1) kolumn för att lagra värdena och tolkar dem som sant eller falskt baserat på en uppsättning regler.

Vid tolkning av numeriska värden i ett booleskt sammanhang, värdet 0 anses vara falsk. Alla värden som inte är noll anses sanna.

MySQL känner igen de booleska bokstaverna TRUE och FALSE och konverterar TRUE till 1 och FALSE till 0 när du lagrar dem.

Datum och tid

MySQL har stöd för att representera datum, tider och kombinationer av de två.

Datum

date typ kan lagra ett datum utan ett tillhörande tidsvärde:

DATE
 

Vid bearbetning av indata för date kolumner, kan MySQL tolka olika format för att bestämma rätt datum att lagra. Delarna måste dock alltid komma i samma ordningsföljd:år, månad och sedan dag. STR_TO_DATE() Funktionen är tillgänglig för att hjälpa till att konvertera andra datumformat till ett format som MySQL tolkar korrekt.

Vid visning av datum använder MySQL YYYY-MM-DD formatera. Du kan använda DATE_FORMAT() funktion för att formatera utdata i andra format.

date typ kan lagra värden från 1000-01-01 till 9999-12-31 .

Tid

time datatyp kan lagra en specifik tid på dagen utan en associerad tidszon eller datum.

Vid bearbetning av indata för time kolumner, kan MySQL tolka flera format för att bestämma rätt tid att lagra. När indata har kolon tolkas det vanligtvis som hh:mm:ss . Alla förkortade värden (med endast en kolumn) kommer att tolkas som att använda hh:mm . När ingången inte gör det har kolon, bearbetas tiden för att fylla upp det minsta värdet först. Till exempel, 1045 tas som 10 minuter och 45 sekunder.

MySQL stöder också bråkdelar av sekunder om ett decimalkomma anges. Den lagrar upp till 6 siffror med precision efter decimalen. Värden i time kolumner kan variera från -838:59:59.000000 till 838:59:59.000000 .

När tidsvärden visas använder MySQL hh:mm:ss formatera. Precis som med datum tillhandahålls en funktion som heter TIME_FORMAT() för att visa tidsvärden med andra format.

Tidsstämplar och datumtid

MySQL kan representera tidsstämplar, en kombination av ett datum och en tid som används för att representera ett specifikt ögonblick i tiden, i två olika varianter:med timestamp typ och datetime typ.

datetime typ kan representera värden från 1000-01-01 00:00:00 till 9999-12-31 23:59:59 . Den kan också inkludera bråkdelar av sekunder med upp till sex siffror som liknar time typ.

timestamp typ kan representera värden från 1970-01-01 00:00:01 UTC till 2038-01-19 03:14:07 UTC. Den klarar också bråkdelar av sekunder. När du lagrar timestamp värden, konverteras alla värden från den givna tidszonen till UTC för lagring och konverteras tillbaka till den lokala tidszonen vid hämtning. datetime typ gör inte detta.

Från MySQL 8.0.19 och framåt kan du inkludera en tidszonförskjutning när du lagrar en timestamp för att explicit ställa in tidszonen för det lagrade värdet. Du gör detta genom att inkludera ett värde efter tidskomponenten, utan mellanslag för att indikera offset. Intervallet av accepterade värden går från -14:00 till +14:00 , som representerar förskjutningen av det lagrade värdet från UTC.

När du bestämmer om du ska lagra datum- och tidsvärden med datetime eller timezone typer är det ofta bra att separera dem efter vad de är bäst för.

Tänk på datetime värden som ett specifikt datum och tid, i förhållande till kalendern och klockan varhelst den hämtas. Om en person går och lägger sig vid 23:00 på natten, en datetime värde kan representera det värdet, oavsett vilken tidszon personen befinner sig i för närvarande.

Å andra sidan, timezone värden är bäst på att representera ett specifikt ögonblick i tid som är otvetydigt över tidszoner. För att skicka en inbjudan till videosamtal, en timezone värde skulle kunna se till att mötet äger rum samtidigt för alla, oavsett vilken tidszon deltagaren befinner sig i.

Andra användbara typer

Tillsammans med de typer som vi täckte med lite djup ovan, finns det ytterligare typer som är användbara i specifika scenarier. Vi kommer att täcka dessa kort för att ge dig en uppfattning om hur du använder dem och när de kan vara användbara.

Räknade och uppräknade typer

Två relaterade typer som tillåter användare att diktera giltiga värden för en kolumn är enum och set typer.

enum typ är en strängtyp som låter användaren definiera en samling giltiga värden när kolumnen skapas. Alla värden som matchar ett av de definierade värdena accepteras och alla andra värden avvisas. Detta fungerar på samma sätt som en rullgardinsmeny genom att ett val kan göras från en specifik uppsättning alternativ. Till exempel en enum kallas season kan skapas med värdena winter , spring , summer och autumn .

För att skapa en enum kolumn, ange typen som enum , som ger de möjliga värdena som strängar, separerade med kommatecken, inom en uppsättning parenteser, så här:

season ENUM('winter', 'spring', 'summer', 'autumn')
 

En liknande typ av användardefinierad typ är set typ. Som enum typ, set typer tillåter användare att ange giltiga värden som strängar vid definition. Skillnaden mellan dessa två typer är den i en set , kan mer än ett värde lagras för varje post.

Om du till exempel behövde en kolumn för att representera veckodagarna volontärer är tillgängliga för att arbeta, kan du ha en set kolumn så här:

availability SET('sunday', 'monday', 'tuesday', 'wednesday', 'thursday', 'friday', 'saturday')
 

När du anger värden för availability kolumn som vi just skapade ger du en enda sträng med kommatecken som skiljer alla dagar som volontären är tillgänglig. Till exempel:

'monday,tuesday,wednesday,thursday,friday''sunday,saturday''monday,wednesday,friday''thursday'
 

För set typer i MySQL, dubbletter av värden i inmatning tas alltid bort och vid hämtning följer värdena den ordning som används i set definition oavsett ordningsföljd vid inmatning i kolumnen.

JSON

MySQL stöder kolumner i JSON med json typ. Data lagras som json lagras i binärt för snabbare exekvering och bearbetning så att servern inte behöver tolka en sträng för att fungera på JSON värden.

JSON
 

För att använda JSON kolumner, tillhandahåller MySQL ett antal funktioner för att arbeta med värden i dokumentet.

Slutsats

I den här artikeln har vi täckt många av de vanligaste datatyperna som är användbara när du arbetar med MySQL-databaser. Det finns ytterligare typer som inte tas upp i den här guiden som är användbara att veta om, men dessa utgör en bra utgångspunkt för de flesta användningsfall.

Det är viktigt att använda typsystemet på rätt sätt så att du kan kontrollera giltiga värden och arbeta med data som förväntat. Det finns fallgropar du kan stöta på om du väljer en typ som inte passar dina data, så att tänka efter innan du bestämmer dig för en datatyp är i de flesta fall värt besväret.

Om du använder Prisma Client för att arbeta med dina MySQL-databaser, kan du hitta en mappning mellan några av de vanliga MySQL- och Prisma-typerna i Prismas MySQL-dataanslutningsdokument.