Hur väljer du datatyper i MySQL, och vilka är vanliga fallgropar?

Question

IT Interview Practice · Accepted Answer

Välj den **minsta typ som korrekt rymmer varje värde** du någonsin kommer att lagra. Rätt typ sparar diskutrymme, krymper index och förhindrar tyst datakorruption.

## Tal

- `INT` (4 byte) för de flesta id:n; `BIGINT` (8 byte) endast när du verkligen växer ur ~2,1 miljarder.
- `DECIMAL(10,2)` för pengar — **aldrig** `FLOAT`/`DOUBLE`, som avrundar binärt och tappar ören.

## Strängar

- `VARCHAR(n)` för begränsad text (namn, e-post); `n` är ett tak, lagringen är bara det du använder.
- `TEXT` för stora blobbar (artiklar) — det lagras utanför sidan och **kan inte ha ett default-värde**; använd det inte för korta värden som du filtrerar på.

## Datum

- `DATETIME` (ingen tidszon, 8 byte) kontra `TIMESTAMP` (UTC-konverterad, 4 byte, ~2038-gräns).

```sql
CREATE TABLE payments (
  id          BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  amount      DECIMAL(10,2) NOT NULL,   -- exact money, not FLOAT
  currency    CHAR(3)       NOT NULL,   -- always 3 chars -> fixed CHAR
  note        VARCHAR(255),             -- bounded, indexable
  created_at  DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Pitfall: the default SQL mode rejects bad values (good) --
INSERT INTO payments (amount) VALUES ('abc');  -- ERROR 1366, not silently 0
```

## Vanliga fallgropar

- Att använda `FLOAT` för pengar.
- `VARCHAR(255)` överallt av gammal vana — överstora nycklar sväller upp index.
- Att lagra datum som strängar, vilket dödar intervallfrågor och sortering.
- Att glömma `UNSIGNED` på id:n/räknare som aldrig är negativa (dubblar det positiva intervallet).

## Varför det är viktigt

Datatyper är det billigaste beslutet om korrekthet och prestanda du fattar, och det svåraste att ändra i efterhand — smala, exakta typer håller index små och stoppar dålig data vid dörren innan den blir en produktionsbugg.

Tal

Strängar

Datum

Vanliga fallgropar

Varför det är viktigt

Relaterade frågor