MySQLのデータ型一覧を完全解説｜用途・特徴・選び方までわかる最新ガイド

1. はじめに：MySQLのデータ型一覧を押さえる意味

MySQLでテーブル設計やアプリケーション連携を行っていると、必ずといっていいほど悩むのが「このカラムには、どのデータ型を使うべきか？」という問題です。
INT にするのか、BIGINT まで必要なのか、文字列は VARCHAR で足りるのか、TEXT のほうがいいのか——こうした判断は一見地味ですが、あとから効いてくる“土台づくり”そのものです。

データ型の選び方を軽視すると、次のような問題が起こりがちです。

• 想定よりデータ量が増え、ストレージを無駄に消費する
• インデックスが肥大化し、クエリ性能がじわじわ落ちていく
• 値の範囲オーバーや桁あふれで、思わぬバグや例外が発生する
• 後から型を変更せざるを得なくなり、大規模な移行作業が発生する

逆にいえば、MySQLのデータ型を体系的に理解し、用途に応じて正しく選べるようになることは、パフォーマンスと保守性の両方を高める一番の近道です。

このページでは、次のような方を主な読者として想定しています。

• これから本格的に MySQL を使ったシステム開発を行うエンジニア
• 既存のテーブル設計を見直したい、バックエンド／インフラ寄りエンジニア
• 用途ごとの「おすすめの型」が知りたい Web 制作者・プログラマ

記事の構成としては、まず MySQL に存在する主なデータ型をカテゴリ別に「一覧」として整理します。そのうえで、数値・文字列・日付・JSON・ENUM/SET といった代表的な型ごとに特徴や用途、選び方のポイントを解説し、最後に設計時にありがちなミスと回避策、よくある質問（FAQ）をまとめます。

単なる「用語の羅列」ではなく、実務のテーブル設計で迷わないための判断材料として使っていただけるように構成していきます。次のセクションから、本題であるデータ型の考え方とカテゴリごとの一覧を見ていきましょう。

2. データ型とは何か／なぜ「正しい型選び」が重要なのか

データベースにおける「データ型（Data Type）」とは、そのカラムにどのような種類の値を格納できるかを定義するルールのことです。
MySQL では、整数・小数・文字列・日付・バイナリ・JSON など、多様なデータ型を用意しており、用途に応じて適切に選び分ける必要があります。

データ型の役割

データ型は、単なる「形式の区分」ではありません。次のような複数の役割を同時に担っています。

• データの種類を制約する（数値か文字列か、真偽値かなど）
• 許容される値の範囲や桁数を決める
• 必要なメモリ量（ストレージ容量）を決定する
• インデックス構造や検索性能に影響する
• 暗黙的な変換や比較方法を左右する（例：文字列型の照合順序など）

つまり、データ型は「データの箱」そのものではなく、データ管理全体に影響する基礎設計です。

型選びを誤るとどうなるか

間違ったデータ型を選ぶと、次のような問題が実務で頻発します。

・ストレージの無駄遣い

たとえば BIGINT（8バイト）で十分なところを、誤って DECIMAL や LONGTEXT を使ってしまうと、想像以上のディスク容量を消費します。

・クエリ性能低下

巨大な TEXT 型に対して LIKE 検索を多用したり、桁数の大きすぎる数値型でインデックスが肥大化すると、SQL の実行速度が落ちやすくなります。

・値の不整合やオーバーフロー

INT では足りない値を格納してしまい、意図せず負の値に変換される、あるいは丸められる…といったトラブルも起こりえます。

・テーブル変更が高コストになる

特に大規模テーブルで型変更 ALTER TABLE を行うと、

• ロック時間が長くなる
• サービスに影響する
• データ移行作業が必要になる
  といったリスクを抱えます。

あらかじめ理解すべきポイント

MySQL のデータ型は大きく以下のカテゴリに分類されます。

• 数値型（整数・小数）
• 文字列型
• 日付・時刻型
• バイナリ型
• JSON型
• ENUM / SET 型
• 空間（Spatial）データ型

それぞれに「強み・弱み」「軽い・重い」「検索しやすい・しにくい」の違いがあり、用途に応じた最適な型選びが求められます。

3. MySQLのデータ型カテゴリ一覧

ここでは、MySQLで利用できるデータ型を 「カテゴリごとに整理した一覧」 としてまとめます。実務でまず確認したいのは「どんな型があるのか」と「どれを使うべきか」です。
そのため、ここでは 用途・特徴・代表的な型名 を分かりやすく示したうえで、後続のセクションでさらに詳しく解説していきます。

3.1 数値データ型（Numeric Types）

数値データ型は、整数・小数・浮動小数など、数値を扱う全ての処理の基盤になります。
ID、数量、金額、フラグ判断など、あらゆる用途で最も多く利用されるカテゴリです。

整数型（Integer）

補足

• UNSIGNED を付けると「正の範囲に2倍」広がります。
• INT を使う場面が非常に多いですが、安易に BIGINT を使うとインデックスが重くなります。

小数・浮動小数点型（Decimal / Floating Point）

補足

• 金額は「DECIMAL 一択」。浮動小数点（FLOAT/DOUBLE）は誤差が発生するため不向きです。
• 演算処理が多い場合、DOUBLE を選ぶケースもあります。

その他の数値型

3.2 日付・時刻データ型（Date and Time Types）

日付・時刻の扱いはアプリケーション開発などで非常に多用されます。
用途によって「タイムゾーンの保持／自動更新／秒精度」などが変わるため、選び分けが重要です。

補足

• 「更新日時」を自動で管理したい場合は TIMESTAMP が便利。
• 「ログ」や「履歴」など正確な時刻を保持するなら DATETIME 型が一般的です。

3.3 文字列・バイナリデータ型（String / Binary Types）

ユーザー名、メール、パスワード、説明文など、文字列はテーブル設計で最も複雑になりやすい領域です。

固定長文字列

可変長文字列

大量テキスト用（TEXT系）

メモ

• 記事本文や説明文など、巨大な文字列を扱う場合にTEXTを使います。
• 検索・インデックス設計に注意が必要です。

バイナリデータ（BINARY / BLOB）

※大型ファイルはDBに格納せず外部ストレージに保存する設計が一般的です。

ENUM / SET 型（列挙型）

注意

• 型定義変更が発生するとメンテナンスが重い
• 小規模・静的な候補であれば有効

3.4 JSON型

• NoSQL的な柔軟さを持ちつつ、JSON専用関数が利用できます。
• ただし 頻繁に検索するデータを JSON に詰め込むのは非推奨。正規化できるものは構造化テーブルにすべきです。

3.5 空間（Spatial）データ型

地理情報や位置情報を扱う場合に利用します。

一般的なWebアプリケーションでは利用頻度は高くありませんが、地図アプリやGPS連携用途では重要になります。

4. 各データ型の選び方・使い分けのポイント

ここでは、前のセクションで紹介したカテゴリを「実務でどう選べば良いのか」という観点から深掘りします。
単に種類を知っているだけでは十分ではなく、目的に合ったデータ型を選び抜くことが、メンテナンス性・性能・将来の拡張性を大きく左右します。

4.1 数値型の選び方

整数型の判断基準

整数型を選ぶ際のポイントは次の3つです。

1. 値の最大範囲を把握する

• 少量のカウンタ → TINYINT
• 商品数量・フラグ → SMALLINT / INT
• 大規模なIDやログ → BIGINT

特に主キーに BIGINT を多用するプロジェクトがありますが、無駄なインデックス容量を生みやすく、性能面で不利になることもあります。

2. UNSIGNED を積極的に検討する

正の値しか扱わない場合（例：数値ID、在庫数）
→ UNSIGNED にすることで範囲が2倍になり、小さな型を使える可能性があります。

3. 金額・精度が必要な値は DECIMAL 一択

「誤差を許容できない値」は FLOAT/DOUBLE を避け、必ず DECIMAL を使います。

4.2 日付・時刻型の選び方

用途ごとに適切な型が異なります。

DATETIME と TIMESTAMP の違い

選び方の一般ルール

• アプリのログやイベント記録
  → DATETIME（タイムゾーン変動の影響を避けたい）
• 更新日時を自動記録したい
  → TIMESTAMP（便利な自動更新特性）

YEAR 型の使いどころ

• 年度分類、発売年、創業年など
  → コンパクトに管理可能（1バイト）

4.3 文字列型の選び方

CHAR / VARCHAR の判断基準

CHAR を使うべきケース

• 長さが常に一定：都道府県コード、国コード、固定長識別子など
• 高速アクセスが必要で、更新頻度が少ないデータ

VARCHAR を使うべきケース

• 長さが可変：名前、メールアドレス、タイトルなど
• 多くの場面で最適解

TEXT 型を使うべきか？

TEXT 型の利点

• 大量テキストに対応（説明文、記事本文など）

TEXT 型の注意点

• インデックスが制限される（prefix インデックスが必要）
• JOIN や WHERE で扱うと性能が落ちやすい
• 検索・並び替えが重い

推奨:
本文やメモなど「大きい文字列は TEXT」、
それ以外は可能な限り VARCHAR を利用。

4.4 JSON 型の選び方

JSON 型は非常に便利ですが、「正しく使う」必要があります。

JSON が向いている場面

• 柔軟な設定項目や、項目数が可変なデータ
• 限定的な参照、もしくはアプリ側で展開する用途
• マスタ不要な軽量データの保持

JSON が向かない場面

• 頻繁に検索するデータ
• 絞り込み検索・集計・JOIN を行うデータ
• 正規化すべき構造化データ

原則:
検索するデータは正規化し、構造として扱うべきです。
JSONは「柔軟だけど検索に弱い」点を忘れないこと。

4.5 ENUM / SET 型の選び方

ENUM 型が適している場面

• 状態が固定：例）ステータス（draft/published/archived）
• 少数の選択肢で値がほぼ変わらない

ENUM 型の注意点

• 値の追加・変更時に ALTER TABLE が必要
• アプリ側と整合性が取れなくなるリスクあり

SET 型の向いている場面

• 複数選択が必要な小規模データ
  （例：対応曜日、タグが数種類しかない場合）

SET 型の注意点

• 値の組み合わせが複雑になる
• 多値の管理が難しくなる場合がある

4.6 バイナリ／BLOB の選び方

BINARY / VARBINARY

• トークン、ID、ハッシュ値など
• 一定長のバイナリ（例：16バイトのUUID）

BLOB 系の利用シーン

• 小規模ファイル、サムネイル画像、暗号化データ

ただし注意

• 大容量ファイルをDBに置くとバックアップが重くなる
• 読み書きの負荷も大きくなる
  → 実務では外部ストレージ＋パス管理が推奨

5. 実践：テーブル設計時に「データ型一覧表」を活用する方法

ここでは、実際に MySQL のテーブル設計を行う際、どうやってデータ型一覧を活用し、最適な型を選んでいくかを 実務フローに沿って解説します。
ただ型を覚えるだけではなく、「なぜその型を選ぶのか」を理論と手順で整理することで、品質の高いデータベース設計ができます。

5.1 ステップ1：カラムの「用途」と「性質」を明確にする

まずは「そのカラムに何を格納するのか」を具体的に定義します。

チェックポイント

• 数値か、文字列か、日付か、フラグか？
• 可変長か、固定長か？
• 最大値・最大文字数は？
• NULL を許容するか？
• 将来増える可能性はあるか？

ここで曖昧なまま進めると、後の型選びが無駄に複雑になります。

5.2 ステップ2：必要な範囲・形式を見積もる

次に、格納する値の 上限・下限・文字数・精度 を見積もります。

例：IDカラム

• 最大件数は数千万？数億？
  → INT で足りるのか、BIGINT にすべきか判断できる

例：商品名

• 平均15〜25文字、最大50文字程度？
  → VARCHAR(50) で十分。TEXT は不要。

例：金額

• 精度が必要か？
  → DECIMAL(10,2) などを選択すべき

5.3 ステップ3：データ量とパフォーマンスを考慮する

MySQLのデータ型選びは、性能にも直結します。

主な観点

• 大きすぎる型 → ストレージを食い、インデックスが重くなる
• TEXT / BLOB → 検索性能が落ちる
• JSON → 柔軟だが検索には弱い
• TIMESTAMP → 自動更新や比較が高速

特にインデックスを張るカラムは、可能な限り軽量な型にするのがポイントです。

5.4 ステップ4：サンプルデータで型を検証する

テーブルを設計したら、実際に数十〜数百行のテストデータを投入して確認します。

確認するポイント

• 意図しない丸めや切り捨てが起きていないか
• VARCHAR で十分か、TEXT にするべきか
• datetime の並び順・検索が期待どおりか
• JSON の読み取り / 書き込み性能

実データに近い値でテストすると「机上の判断ミス」が減ります。

5.5 ステップ5：拡張性・運用性も考慮する

テーブル設計の最終段階では、「将来変更が容易か？」をチェックします。

型変更が重い代表例

• ENUM（値追加時に ALTER TABLE が必要）
• TEXT → VARCHAR（逆は容易だが、縮小は危険）
• FLOAT → DECIMAL（意味が変わる可能性）

「将来拡張が見込まれるかどうか」を判断し、型を選びます。

5.6 ステップ6：CREATE TABLE の例（実践的サンプル）

以下は、一般的な Web アプリケーションでよく使うデータ型の採用基準を反映したテーブル例です。

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

この例のポイント

• id：将来の規模を見越して BIGINT UNSIGNED
• name：中程度の可変長文字列 → VARCHAR
• price：金額 → 誤差のない DECIMAL
• stock：在庫数 → INT UNSIGNED
• status：固定値を扱うので ENUM
• description：長文の可能性があるため TEXT
• updated_at：自動更新が便利な TIMESTAMP

このように、型選択には必ず「理由」が存在し、それを言語化できることが望ましい設計です。

6. よくある誤りと回避策

MySQL のデータ型は選択肢が多いため、実務では「ありがちな失敗」がいくつか存在します。
このセクションでは、開発現場でよく見られる誤りを取り上げ、それぞれに対する回避策を提示します。

6.1 過剰に大きなデータ型を使ってしまう

ありがちな例

• すべての ID を BIGINT にしてしまう
• 文字列を何でもかんでも VARCHAR(255) にしてしまう
• 文章でないのに TEXT を使ってしまう

問題点

• ストレージの無駄
• インデックスが肥大化して検索性能に悪影響
• ネットワーク帯域の無駄（データ転送量が増える）

回避策

• 格納される値の最大・最小を事前に予測する
• VARCHAR の最大長さは根拠を持って設定する
• 本当に長文になる場合のみ TEXT を選択する

6.2 小数を FLOAT/DOUBLE で扱ってしまう（誤差問題）

ありがちな例

• 金額を FLOAT にしてしまう
• 数値比較が誤差のせいで一致しない

回避策

• 金額・精度の必要な数値は DECIMAL を使う
• 科学計算や一時的な数値処理以外は FLOAT/DOUBLE を避ける

6.3 VARCHAR が大きすぎる

ありがちな例

• VARCHAR(255) をデフォルトにしてしまう
• 実際は 30 文字程度しか使わないカラムまで長く設定する

問題点

• メモリ・ストレージの無駄
• インデックスが重くなる場合が多い

回避策

• 平均・最大文字数をデータから推測する
• 必要以上に大きくしない（例：メールアドレスは VARCHAR(100) など）

6.4 TEXT 型を乱用してしまう

ありがちな例

• 文字列 = TEXT と考えてしまう
• フィルタリングや検索対象なのに TEXT にしてしまう

問題点

• インデックス制限が多い
• LIKE 検索が重い
• JOIN に絡むと処理が遅くなる

回避策

• 説明文や本文など長文のみ TEXT
• 検索に使う文字列はできるだけ VARCHAR で保持

6.5 日付・時刻型の性質を理解せず選んでしまう

ありがちな例

• すべて DATETIME にしてしまう
• 更新日時を DATETIME にしてしまい、自動更新されない
• タイムゾーンの違いで時刻がズレる

回避策

• 自動更新したい：TIMESTAMP
• 時刻の変動を避けたい：DATETIME
• 年だけ必要：YEAR

6.6 ENUM / SET を安易に使う

ありがちな例

• 選択肢が変わる可能性があるのに ENUM を使う
• カンマ区切りのように SET を使ってしまう

問題点

• 変更が入ると ALTER TABLE が必要
• アプリ側の定義と不整合が発生しやすい

回避策

• 値が増える可能性があるなら別テーブルでマスタ管理
• 小規模かつ固定値のみ ENUM を使う

6.7 JSON を「便利だから」と詰め込みすぎる

ありがちな例

• 本来は正規化すべき構造を JSON に詰め込む
• 頻繁に検索するデータを JSON の中に格納する

問題点

• 検索性能が低下
• インデックスが効きにくい
• アプリ側でのパース処理が増える
• スキーマレスゆえに整合性が崩れやすい

回避策

• 検索しないデータ だけ JSON にする
• 設定情報など “可変の小データ” に限定
• JOIN / 検索に使う情報は正規化する

6.8 型変更のコストを甘く見てしまう

問題点

• ALTER TABLE が大規模テーブルだと非常に重い
• サービス停止やロック時間が長くなる
• データ移行が必要になるケースもある

回避策

• 設計段階で将来の値増加を見越す
• ENUM は慎重に使う
• DECIMAL の桁数は余裕を持たせる（過剰はNG）

7. まとめ

MySQL では非常に多くのデータ型が提供されており、どれを使うかによって 性能・拡張性・保守性が大きく変わる ことを見てきました。
特に Web アプリケーションのようにデータ量が増えやすい環境では、初期設計の判断が長期的な品質に直結します。

本記事で押さえた重要ポイント

• データ型は「値の種類・範囲・精度・ストレージ・パフォーマンス」に影響する重要な要素
• 数値、文字列、日付、JSON、ENUM/SET、BLOB など、それぞれに特徴と向き不向きがある
• 特に整数・文字列・日付は使用頻度が高く、選び分けが重要
• JSON や ENUM は便利だが、使い方を誤ると保守が困難になる
• TEXT や BLOB の乱用は性能低下の原因になる
• テーブル設計は「用途 → 範囲 → 性能 → 拡張性」の順で考えるのが合理的

今日から実践できる設計チェックリスト

• そのカラムの「用途」は明確か
• 格納する値の最大・最小を把握しているか
• VARCHAR の長さに根拠があるか
• 金額は DECIMAL を使っているか
• 更新日時は TIMESTAMP や自動更新で管理できているか
• ENUM を使う前に“値が将来増えるか”を検討したか
• JSON に詰め込んで検索が遅くなる設計をしていないか
• 大量データの ALTER TABLE が発生しないよう設計できているか

最後に

MySQL のデータ型選びは「正解がひとつ」という世界ではありません。
しかし、用途と将来性を意識して選べば、大きな問題を未然に防ぎ、クリーンなデータ構造を保つことができます。

最終的には、プロジェクトの性質・データ量・アプリの特性によって最適解が変わりますが、本記事で紹介した判断基準を土台にすれば、どんな状況でもより良いデータ型選びができるはずです。

次は、実務で頻繁に聞かれる疑問をまとめた FAQ セクション をご紹介します。
データ型選びで迷ったとき、まずこの FAQ を参照することで判断がスムーズになります。

8. FAQ（よくある質問）

MySQL のデータ型選びは、実務経験の有無によって判断が大きく変わる部分です。
ここでは、実際の開発現場で頻出する質問をまとめ、短く明確な回答を提示します。

Q1. INT と BIGINT はどちらを使えば良いですか？

A：基本は INT。将来 21 億を超える可能性がある場合のみ BIGINT。

INT（4バイト）は約 21 億まで扱え、ほとんどのアプリケーションで十分です。
ログや大量トラフィックを扱うサービス、非常に大規模な ID 発行を想定する場合は BIGINT を検討します。

Q2. VARCHAR と TEXT、どちらを使うべきですか？

A：検索が必要なら VARCHAR、長文なら TEXT。

• VARCHAR：インデックスが効きやすく検索向き
• TEXT：長文向けだが検索やJOINに不向き

※TEXTを多用すると性能劣化につながります。

Q3. 金額は DOUBLE で扱っても大丈夫ですか？

A：NG。必ず DECIMAL を使います。

DOUBLE や FLOAT は誤差が出るため、金額・精度が求められる値には不向きです。
業務システムでは DECIMAL(10,2) や DECIMAL(12,2) が標準です。

Q4. DATETIME と TIMESTAMP の違いが分かりません。どう選ぶべき？

A：自動更新が必要なら TIMESTAMP、正確な時刻保持なら DATETIME。

• TIMESTAMP：自動更新・タイムゾーン変換あり
• DATETIME：タイムゾーンの影響なし、純粋な日時を保持

ログ・履歴系には DATETIME が使われることが多いです。

Q5. ENUM は使っても大丈夫ですか？

A：値が“絶対に変わらない”場合のみ有効。

ENUM は軽量で便利ですが、値の追加・変更には ALTER TABLE が必要です。
将来追加がありそうな項目は 別テーブルのマスタ管理が推奨されます。

Q6. JSON はとりあえず使っていいですか？

A：検索しないデータだけ JSON。検索するものは正規化すべき。

JSONは柔軟ですが、性能面では弱点があります。

• 検索に弱い
• インデックス構造が複雑になる
• データ整合性が保ちにくい

設定やオプションなど「検索対象にならない属性」のみ JSON を使うと良いです。

Q7. VARCHAR の最大長さはどう決めれば良いですか？

A：実データの最大値を推測し、少し余裕を持たせる。

例：メールアドレス → VARCHAR(100) で十分
例：ユーザー名 → VARCHAR(50) 程度で問題ないことが多い

“何となく 255” は NG です。

Q8. 型を間違えた場合、後から変更できますか？

A：できますが、大規模テーブルでは非常に重い処理です。

ALTER TABLE はフルスキャンや再構築を伴うため、
サービス停止やロック時間が発生することもあります。

→ 最初の設計段階の慎重さが最も重要です。