SQLのint型とは？サイズ・RDBMS別の違いとオートインクリメント、実務での注意点を徹底解説

2025年11月18日 最終更新日時 : 2025年11月18日 エバープレイ編集部

SQL の int 型とは — 基本から実務での注意点まで

データベースで数値を扱うとき、特に整数を扱うための型として最も頻繁に使われるのが「int（INTEGER）」です。本コラムでは「SQL:int型とは」をテーマに、定義・サイズ・各RDBMSの差異・自動増分・性能や設計上の注意点まで、実務で役立つ情報を詳しく解説します。

概要：int（INTEGER）の役割

int（または integer）は、符号付き整数を表すデータ型で、多くのRDBMSでは 4 バイト（32 ビット）の整数を指します。主にIDやカウント、フラグ（0/1）など、少数の小さな整数を扱う場面で使われます。SQL 標準でも INTEGER 型は定義されていますが、実際のバイト数や追加の整数型（SMALLINT、BIGINT など）は実装ごとに異なります。

主な整数型とサイズ・範囲（一般的な実装）

  • TINYINT: 1 バイト（MySQL 等）。符号付き: -128 ～ 127、符号なし: 0 ～ 255
  • SMALLINT: 2 バイト。符号付き: -32,768 ～ 32,767
  • INT / INTEGER: 4 バイト。符号付き: -2,147,483,648 ～ 2,147,483,647（標準的）
  • MEDIUMINT: 3 バイト（MySQL 固有）。符号付き: -8,388,608 ～ 8,388,607
  • BIGINT: 8 バイト。符号付き: -9,223,372,036,854,775,808 ～ 9,223,372,036,854,775,807

上記は代表的な値であり、RDBMS によっては「unsigned（符号なし）」をサポートして上限が変わります（例：MySQL の UNSIGNED）。ただし PostgreSQL は標準で unsigned 型を提供しません。

主要な RDBMSごとの特徴

MySQL

  • INT は 4 バイト。UNSIGNED を付けると 0 ～ 4,294,967,295 の範囲になる。
  • TINYINT（1 バイト）、SMALLINT（2 バイト）、MEDIUMINT（3 バイト）、INT（4 バイト）、BIGINT（8 バイト）を提供。
  • INT(M) の M は表示幅（display width）を示すが、8.0.17以降はほとんど無視される（ZEROFILL を用いる場合を除く）。
  • デフォルトの SQL モードにより、範囲外の値を挿入した際にエラーになるか、近似値で丸められるかが変わる（STRICT モードではエラー）。

PostgreSQL

  • integer は 4 バイト。smallint（2 バイト）、bigint（8 バイト）も提供。
  • unsigned integer のネイティブ型は存在しない（拡張で実現可能だが一般的ではない）。
  • 連番用に SERIAL（内部的にシーケンス）や、SQL標準の IDENTITY を利用するのが一般的（smallserial / serial / bigserial）。
  • 範囲外の数値挿入はエラーになる。

Microsoft SQL Server

  • tinyint（1 バイト, 0–255）、smallint（2 バイト）、int（4 バイト）、bigint（8 バイト）を提供。
  • SQL Server の tinyint は符号なし（0–255）である点が他と異なる。
  • 自動増分には IDENTITY 句を使用する。

SQLite

  • 型システムは動的。INTEGER 型は最大 8 バイトの整数を格納できる（実際の格納は値により変わる）。
  • PRIMARY KEY に INTEGER を指定すると、そのカラムは内部の rowid のエイリアスとなる（自動増分のように振る舞う）。

自動増分（オートインクリメント）の扱い

主キーに連番を用いる場合、各 RDBMS は独自の仕組みを提供します。

  • MySQL: AUTO_INCREMENT キーワード
  • PostgreSQL: SERIAL / BIGSERIAL（シーケンスを内部で利用）、PostgreSQL 10 以降では IDENTITY 句が標準に近い
  • SQL Server: IDENTITY(seed, increment)
  • SQLite: INTEGER PRIMARY KEY を指定すると rowid が使われる
-- MySQL 例
CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100)
);

-- PostgreSQL 例 (serial)
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100)
);

パフォーマンスと設計上のベストプラクティス

  • 整数は文字列よりも比較・演算・インデックス効率で優れる。ID やカウンタには整数を使うべき。
  • 予想される最大値に応じて最小の型を選ぶ。小さい型を選べばインデックスとディスクの消費が減り、I/O とキャッシュ効率が向上する。
  • ただし「過度に小さい型を選ぶ」ことで後にオーバーフローし、ALTER TABLE を頻繁に行う羽目にならないよう注意する。将来の成長を見越す。
  • 可搬性も考慮。UNSIGNED を多用すると PostgreSQL などへ移行する際に互換性の問題が発生する。
  • GUID（UUID）などの代替を使う場合、サイズやインデックス性能を考慮。分散ノードでの一意性が必要な場合に検討。

オーバーフロー・境界値の扱い

  • 多くの RDBMS は範囲外の挿入に対してエラーを返す（PostgreSQL、SQL Server等）。MySQL は SQL モードにより警告で処理される場合がある。
  • 算術演算の結果が型の範囲を超えるとエラーやトランケションのロールバックになることがある。大きな数を扱う演算では型の拡張を検討する（BIGINT 等）。

NULL、デフォルト値、キャスト

  • 整数カラムは NULL を許容するかどうかを設計段階で決定する。NULL を許可すると検索や集計に注意が必要。
  • デフォルト値は DEFAULT 句で指定。AUTO_INCREMENT/IDENTITY を使っている場合は通常 DEFAULT を指定しない。
  • 文字列から整数へのキャストは DB によって挙動が異なる（暗黙の型変換、エラー、切り捨て等）。明示的な CAST() を使うと安全。

実務でのよくある誤解と注意点

  • 「INT は常に 32 ビット」と思い込むのは危険。実装依存の差異に注意（SQLite のような特殊実装もある）。
  • UNSIGNED を使うと見かけ上プラスの幅が広がって便利だが、負の値が不要であることを十分確認すること。また移植性が落ちる点に注意。
  • 表示幅（INT(M)）は値の保存に影響しない（MySQL 固有の表示指定に過ぎない）。
  • 主キーに INT を使うと将来的に上限に達する可能性があり、急成長が見込まれるサービスでは最初から BIGINT を選ぶことがよくある。

簡単な設計ガイドライン（チェックリスト）

  • そのカラムの最大想定値は？ → SMALLINT / INT / BIGINT を選定する。
  • 負の値は必要か？ → 必要なら signed、不要なら unsigned（ただし互換性を考慮）。
  • 主キーか単なる属性か？ → 主キーならインデックス負荷を考え、場合により BIGINT を検討。
  • 自動採番が必要か？ → AUTO_INCREMENT、SERIAL、IDENTITY、INTEGER PRIMARY KEY（SQLite）を使う。
  • 移行や他DBとの互換性を考慮し、DBMS 固有の拡張に依存し過ぎない。

まとめ

SQL の int 型は「整数」を効率的に扱う基本的な型であり、各 DBMS でおおむね 32 ビット（4 バイト）を意味しますが、実装差異（サイズ、符号、特殊型、オートインクリメントの実装、オーバーフローの挙動など）には注意が必要です。設計では将来の成長や移植性、索引サイズを意識して型を選びましょう。

参考文献

カテゴリー
IT
前の記事
頭脳警察完全ガイド：名盤・代表曲から歌詞の思想、ライブの魅力と現代への影響までNew!!
2025年11月18日
次の記事
ドナルド・フェイゲン（Steely Dan）徹底ガイド：音楽性・代表作・プロダクションと聴きどころNew!!
2025年11月18日