SQLのデータ型一覧と選び方｜性能・精度・拡張性を左右する設計の基本

「INTとBIGINTはどちらを選ぶべきか？」「金額はFLOATで問題ないのか？」「VARCHARはどこまで長く設定すべきか？」
SQLのデータ型選びで迷った経験はないでしょうか。

データ型は単なる“入れ物”ではありません。
データの正確性、検索性能、インデックス効率、ストレージコスト、将来の拡張性に直結する、データベース設計の中核です。

本記事では、以下を体系的に解説します。

• SQLデータ型の基礎知識
• 数値・文字列・日時・バイナリ型の実務的な選び方
• MySQL・SQL ServerなどDB製品間の違い
• 現場で頻発する失敗例と回避策
• 移行や拡張を見据えた設計指針

初心者にも理解できる解説と、実務経験者が納得する深さを両立させた内容です。
スキーマ設計で迷わないための“判断基準”を持ち帰ってください。

SQLのデータ型とは？なぜ重要なのか

SQLのデータ型とは、「その列にどんな値を、どの形式で、どこまで保存できるか」を定義する仕組みです。

データ型が影響する4つの要素

1. データの正確性（整合性）

2. 検索・結合の性能

3. ストレージ効率

4. 将来の拡張性

たとえば：

• 数値列に文字列が入らない
• 日付列に不正フォーマットが入らない
• 金額計算で誤差が出ない

これらはすべてデータ型によって守られています。

また、型が異なるとインデックスサイズやI/O回数が変わるため、大規模データでは性能差が顕著になります。

SQL標準仕様については、ISO/IEC 9075（SQL標準）を参照できます。

参考：https://www.iso.org/standard/76583.html

データ型を選ぶ5つの判断基準

1. 値の範囲（オーバーフロー防止）

• 将来どこまで増えるか？
• 最大値は業務上いくつか？

例：10億件を超える可能性があるならINTではなくBIGINTを検討。

2. 精度（誤差許容度）

• 金額 → 固定小数点（DECIMAL）
• センサー値 → 浮動小数点（FLOAT）

「近似でよいか、完全一致が必要か」が分岐点です。

3. 桁数と容量

型が大きすぎると：

• インデックス肥大化
• ページあたり格納行数減少
• I/O増加

必要最小限＋将来余裕が原則。

4. 検索・結合への影響

暗黙の型変換が起きると：

• インデックスが効かない
• フルスキャンになる
• 性能劣化

列の型とクエリはセットで設計することが重要です。

5. 移行・互換性

MySQL → SQL Server
オンプレ → クラウド移行

を想定するなら、標準型を優先するのが安全です。

数値型の選び方

数値型は大きく3分類です。

整数型（TINYINT / SMALLINT / INT / BIGINT）

原則：最小サイズを選ぶ

• 小さい型 → インデックス効率向上
• 大きすぎる型 → 無駄な容量消費

典型用途

• ID
• 並び順
• ステータスコード
• フラグ

実務ポイント

• AUTO_INCREMENTやIDENTITY列は枯渇リスクを計算
• 分散環境ではIDの桁飛びを想定

浮動小数点型（FLOAT / DOUBLE）

特徴

• 近似値
• 丸め誤差あり
• 等価比較に不向き

向いている用途

• センサー値
• 統計値
• 科学技術計算

IEEE 754仕様に基づく演算誤差については以下が参考になります。
https://ieeexplore.ieee.org/document/8766229

固定小数点型（DECIMAL / NUMERIC）

特徴

• 誤差なし
• 精度（p）とスケール（s）を指定

例：

DECIMAL(10,2)

必須用途

• 金額
• 税率
• 在庫数量

注意点

• 計算途中で桁あふれが起きる
• 精度不足によるエラー

文字列型の選び方

固定長（CHAR）

向いているケース：

• 郵便番号
• 固定桁コード

注意

末尾空白パディングの挙動を確認。

可変長（VARCHAR）

最も一般的。

設計のコツ

• 仕様上の最大値を参考に設定
• 無制限相当型は極力避ける
• インデックス列は長さを抑える

大容量（TEXT / CLOB）

用途：

• 記事本文
• HTML
• ログ

実務上の最適解

• 本文は別テーブルに分離
• 検索用に要約カラムを持つ
• 全文検索エンジン利用

MySQL全文検索について：

https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html

日付・時刻型の選び方

DATE

• 誕生日
• 請求日
• 締め日

時刻不要ならDATE一択。

TIME

• 営業開始時刻
• シフト開始時刻

秒以下精度は必要最小限。

DATETIME / DATETIME2 / TIMESTAMP

実務ルール

• 保存はUTC
• 表示でローカル変換
• created_at / updated_atを標準化

タイムゾーン設計参考：https://www.iana.org/time-zones

ブール型（BOOLEAN / BIT）

注意点：

• SQLは3値論理（TRUE / FALSE / NULL）
• NULLの意味を明確化

必ずNOT NULL＋デフォルト値を検討。

バイナリ型（BINARY / VARBINARY / BLOB）

用途：

• 暗号ハッシュ
• 画像
• PDF

実務判断

• ハッシュ → 固定長
• 画像 → オブジェクトストレージ推奨
• DB肥大化防止設計が重要

DB製品別の違い

MySQL

• BOOLEANは実質TINYINT
• TEXT/BLOB種別が多い

公式ドキュメント：https://dev.mysql.com/doc/

SQL Server

• VARCHAR(MAX)
• ROWVERSION（旧TIMESTAMP）

公式：https://learn.microsoft.com/sql/

Access

• 型制限あり
• 制約表現に制限

よくある失敗例

❌ 金額にFLOATを使う
→ 誤差発生

❌ VARCHAR(1000)を多用
→ インデックス肥大

❌ TIMESTAMPの意味誤解
→ 移行時破綻

❌ NULL設計を曖昧にする
→ 条件漏れ

実務で迷わないための設計チェックリスト

• 正確性が最優先の列は？
• 将来増え続ける列は？
• 検索キーは最適サイズか？
• NULLの意味は定義済みか？
• 移行前提で設計されているか？

まとめ｜データ型設計は“性能と品質の土台”

SQLのデータ型は単なる仕様項目ではありません。

• 正確性
• 性能
• 拡張性
• 移行耐性

すべての土台です。

正しい型選定は、将来のトラブルと性能劣化を未然に防ぎます。

もしこの記事の内容が「面白い」「もっと深く設計を突き詰めたい」と感じたなら、あなたはすでに設計志向のエンジニアです。

私たちは、データベース設計・パフォーマンスチューニング・アーキテクチャ設計に本気で向き合うチームです。

単なるCRUD開発ではなく、

• 数千万レコード規模の最適化
• マルチDB環境の設計
• 将来移行を見据えたスキーマ設計

といった高度な設計に挑戦しています。

データを正しく設計できるエンジニアと一緒に、より強いシステムを作りたい。

もしSQL設計に本気で向き合いたいなら、ぜひ私たちの採用情報もご覧ください。
同じ志向を持つ仲間をお待ちしています。