MySQLでデータ型をどのように選びますか。また、よくある落とし穴は何ですか。

Question

IT Interview Practice · Accepted Answer

格納しうるすべての値を正しく保持できる**最小の型**を選びます。適切な型はディスクを節約し、インデックスを小さくし、気づかないうちに起こるデータ破損を防ぎます。

## 数値

- ほとんどのidには`INT`（4バイト）。約21億を本当に超える場合にのみ`BIGINT`（8バイト）。
- 金額には`DECIMAL(10,2)`。`FLOAT`/`DOUBLE`は**絶対に使わない**。これらは2進数で丸められ、セント（端数）を失います。

## 文字列

- 長さに上限のあるテキスト（名前、メールアドレス）には`VARCHAR(n)`。`n`は上限であり、使った分だけ格納されます。
- 大きなデータ（記事など）には`TEXT`。ページ外に格納され、**デフォルト値を持てません**。フィルタ条件に使う短い値には使わないでください。

## 日付

- `DATETIME`（タイムゾーンなし、8バイト）と`TIMESTAMP`（UTC変換、4バイト、約2038年の上限あり）の対比。

```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
```

## よくある落とし穴

- 金額に`FLOAT`を使う。
- 習慣でどこでも`VARCHAR(255)`を使う。過大なキーはインデックスを肥大化させます。
- 日付を文字列として格納する。範囲クエリやソートが台無しになります。
- 決して負にならないid/カウントで`UNSIGNED`を付け忘れる（正の範囲が2倍になります）。

## なぜ重要なのか

データ型は、下せる中で最も低コストな正しさとパフォーマンスの判断であり、後から変えるのが最も難しいものでもあります。狭く正確な型はインデックスを小さく保ち、不正なデータが本番のバグになる前に入口で食い止めます。

数値

文字列

日付

よくある落とし穴

なぜ重要なのか

関連する質問