MySQL入門！INTとBIGINTの違いを徹底解説｜テーブル作成とデータ型の基本

1. データベースの「データ型」とは？

1. データベースの「データ型」とは？

まず最初に「データ型」という言葉について説明します。プログラミングやデータベースの世界では、保存する情報の「種類」をあらかじめ決めておく必要があります。

例えば、料理をするときに「液体はコップに」「野菜はザルに」「お肉はバットに」と分けるのと同じです。 MySQLというデータベースでも、**「これは数字を入れる場所ですよ」「これは文字を入れる場所ですよ」**とルールを決めることで、コンピューターが迷わず素早く処理できるようになります。

今回紹介する **INT（イント）** と **BIGINT（ビッグイント）** は、どちらも「整数（小数点のつかない数字）」を扱うためのデータ型です。

2. INT（整数型）の特徴と役割

2. INT（整数型）の特徴と役割

**INT** は「Integer（インテジャー）」の略で、日本語では「整数」という意味です。 MySQLの中で最もよく使われる数字のデータ型で、一般的な数値であればほとんどの場合、このINTで事足ります。

INTが保存できる数字の範囲は、約 **マイナス21億からプラス21億** までです。 「21億なんて使い切れないよ！」と思うかもしれませんが、世界中の人口を数えたり、人気ゲームのスコアを保存したりすると、意外とこの壁にぶつかることがあります。

例えば、ユーザーの年齢や、商品の個数、テストの点数などはINTを使うのが一般的です。

3. BIGINT（巨大整数型）の特徴と役割

3. BIGINT（巨大整数型）の特徴と役割

**BIGINT** は、その名の通り「大きなINT」です。 INTでは入りきらないような、とてつもなく大きな数字を扱うために用意されています。

BIGINTが保存できる範囲は、なんと **約900京（けい）** という、想像もつかないような桁数です。 1億の1億倍が1兆で、そのさらに1万倍が1京ですから、一生かかっても数えきれないほどの大きさですね。

「じゃあ全部BIGINTにすれば安心じゃない？」と思うかもしれませんが、BIGINTはINTの **2倍の保存スペース（8バイト）** を消費します。 データが数件なら気になりませんが、これが数百万件、数億件と増えていくと、データベースが重くなってしまう原因になります。

4. テーブル作成でINTを使ってみよう

4. テーブル作成でINTを使ってみよう

それでは、実際にテーブルを作ってみましょう。今回は「会員サイトのユーザー一覧」を作る想定です。 「ユーザーID」や「年齢」は、21億を超えることはまずないので、INTを使います。

まず、操作前のイメージ（空のテーブル）は以下の通りです。

id (INT) | name (VARCHAR) | age (INT)
---------+----------------+----------
(データなし)

以下のSQLコードで、実際にテーブルを作成し、データを追加してみます。

-- 会員テーブルを作成
CREATE TABLE members (
    id INT,
    name VARCHAR(50),
    age INT
);

-- データを追加
INSERT INTO members (id, name, age) VALUES (1, '田中太郎', 28);
INSERT INTO members (id, name, age) VALUES (2, '佐藤美咲', 34);
INSERT INTO members (id, name, age) VALUES (3, '鈴木健一', 45);
INSERT INTO members (id, name, age) VALUES (4, '高橋洋子', 22);

実行後のテーブルの状態です。

id | name     | age
---+----------+----
1  | 田中太郎 | 28
2  | 佐藤美咲 | 34
3  | 鈴木健一 | 45
4  | 高橋洋子 | 22

5. BIGINTが必要になるケース

5. BIGINTが必要になるケース

では、どんな時にBIGINTが必要になるのでしょうか？代表的な例は **「SNSの投稿ID」** や **「アクセスログ」** です。

例えば、Twitter（X）のようなサービスでは、世界中で1秒間に何万件もの投稿が行われます。 サービス開始から何年も経つと、投稿の総数は21億をあっという間に超えてしまいます。もしここをINTにしていたら、21億件目以降の投稿が保存できず、システムが壊れてしまいます。

また、お金の計算（日本円ではなく、より細かい単位を扱う場合）や、ナノ秒単位の時間計測などでもBIGINTが使われます。

post_id (BIGINT) | content (TEXT)         | likes (INT)
-----------------+------------------------+------------
(データなし)

巨大な数値を扱うテーブルを作成する例です。

-- 投稿テーブルを作成（IDにBIGINTを使用）
CREATE TABLE posts (
    post_id BIGINT,
    content TEXT,
    likes INT
);

-- 21億を超えるような大きなIDを想定
INSERT INTO posts (post_id, content, likes) VALUES (3000000000, 'こんにちは！', 150);
INSERT INTO posts (post_id, content, likes) VALUES (3000000001, 'MySQLの勉強中', 85);
INSERT INTO posts (post_id, content, likes) VALUES (3000000002, 'お腹が空いたな', 10);
INSERT INTO posts (post_id, content, likes) VALUES (3000000003, '今日は晴れです', 300);

実行後のテーブルの状態です。

post_id    | content        | likes
-----------+----------------+------
3000000000 | こんにちは！   | 150
3000000001 | MySQLの勉強中  | 85
3000000002 | お腹が空いたな | 10
3000000003 | 今日は晴れです | 300

6. 符号なし（UNSIGNED）という魔法の言葉

6. 符号なし（UNSIGNED）という魔法の言葉

INTやBIGINTには **「UNSIGNED（アンサインド）」** という設定を追加することができます。 これは「マイナスの数字は使いません！」という宣言です。

例えば、年齢や商品の在庫数にマイナスはありませんよね。 マイナスを禁止にすると、その分プラス側に扱える範囲が広がります。 INTであれば、通常は約21億までですが、UNSIGNEDをつけると **約42億** まで保存できるようになります。

7. 在庫管理システムでの使い分け例

7. 在庫管理システムでの使い分け例

より実践的な例として、在庫管理テーブルを作ってみましょう。 商品のIDや在庫数はINTで十分ですが、売上の累計額（非常に高額になる可能性がある）にはBIGINTを使ってみます。

item_id (INT) | item_name (VARCHAR) | stock (INT) | total_sales (BIGINT)
--------------+---------------------+-------------+---------------------
(データなし)

-- 在庫テーブルを作成
CREATE TABLE inventory (
    item_id INT UNSIGNED,
    item_name VARCHAR(100),
    stock INT,
    total_sales BIGINT
);

-- データを挿入
INSERT INTO inventory (item_id, item_name, stock, total_sales) 
VALUES (101, '高級腕時計', 5, 500000000);
INSERT INTO inventory (item_id, item_name, stock, total_sales) 
VALUES (102, 'スポーツカー', 2, 12000000000);
INSERT INTO inventory (item_id, item_name, stock, total_sales) 
VALUES (103, '鉛筆', 1000, 50000);
INSERT INTO inventory (item_id, item_name, stock, total_sales) 
VALUES (104, 'ノートPC', 50, 7500000);

実行後のテーブルの状態です。

item_id | item_name    | stock | total_sales
--------+--------------+-------+-------------
101     | 高級腕時計   | 5     | 500000000
102     | スポーツカー | 2     | 12000000000
103     | 鉛筆         | 1000  | 50000
104     | ノートPC     | 50    | 7500000

8. なぜ「適切な型」を選ぶのが重要なのか？

8. なぜ「適切な型」を選ぶのが重要なのか？

最後に、なぜ初心者がこの使い分けを学ぶ必要があるのかをお話しします。 それは、データベースは **「一度作ると後から変更するのが大変」** だからです。

サービスが成長して、データが何千万件も溜まった後に「あ、INTじゃ足りなくなったからBIGINTに変えよう」と思っても、その変更作業だけでシステムを何時間も止めなければならなくなったり、最悪の場合データが消えてしまったりするリスクがあります。

最初から「この項目は将来どれくらいの数字になるかな？」と想像力を働かせることが、優秀なエンジニアへの第一歩です。

以下のコードは、テーブルの構造を後から確認するための命令です。これを使って、自分が作ったテーブルが意図した型になっているかチェックできます。

-- テーブルの設計図（構造）を確認する
DESCRIBE inventory;

実行結果の例です。

Field       | Type            | Null | Key | Default | Extra
------------+-----------------+------+-----+---------+-------
item_id     | int unsigned    | YES  |     | NULL    |
item_name   | varchar(100)    | YES  |     | NULL    |
stock       | int             | YES  |     | NULL    |
total_sales | bigint          | YES  |     | NULL    |

9. 初心者が使い分けるためのチェックリスト

9. 初心者が使い分けるためのチェックリスト

どちらを使うべきか迷ったら、以下の基準を参考にしてください。

• INTを使うべき時：
• 人間の年齢（せいぜい150まで）
• 商品の在庫数（数百万個あれば十分）
• 都道府県の番号（1〜47）
• テストの点数（0〜100）


• BIGINTを使うべき時：
• 世界中のユーザーに割り振るID
• SNSの投稿や「いいね」の総数
• 企業の売上金額（円単位の場合）
• 非常に細かい時間の記録（ミリ秒・ナノ秒）

基本的には「迷ったらINT」で大丈夫ですが、**「累計」や「ID」** という言葉が出てきたら「BIGINTの方がいいかな？」と一度立ち止まって考えてみてくださいね。

まとめ

まとめ

MySQLにおける数値データ型の選択は、データベース設計の根幹を成す重要なステップです。今回の記事では、主に整数を扱うためのINT型とBIGINT型の違い、そしてそれらをどのように実務で使い分けるべきかを詳しく解説しました。

MySQLの整数型（INTとBIGINT）の決定的な違い

MySQLのデータベースエンジニアが最も頻繁に使用するデータ型が「INT」です。しかし、システムの規模や扱うデータの性質によっては「BIGINT」を選択しなければならない場面が多々あります。これら二つの型の最大の違いは、扱える数値の範囲（桁数）と、ディスクやメモリを消費するストレージサイズにあります。

最適なデータ型選びがSEOやパフォーマンスに与える影響

「大は小を兼ねる」という考え方で、すべてのカラムをBIGINTに設定してしまうのは、プロフェッショナルな設計とは言えません。なぜなら、ストレージサイズが2倍になるということは、インデックス（索引）のサイズも膨らみ、結果としてデータベースの検索速度（クエリのパフォーマンス）に悪影響を及ぼすからです。高速なレスポンスが求められるウェブサイトにおいて、データベースの最適化は間接的にユーザー体験（UX）を向上させ、検索エンジンからの評価にもつながります。

実例で見る：INTとBIGINTを組み合わせた注文管理システム

例えば、ECサイトの注文管理テーブルを考えてみましょう。注文ID（order_id）は世界中で大量に発生するためBIGINTを使い、注文個数（quantity）はINTで十分です。

order_id (BIGINT) | product_name (VARCHAR) | quantity (INT) | price (INT)
------------------+------------------------+--------------+------------
(データなし)

-- 注文管理テーブルの作成
CREATE TABLE orders (
    order_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    product_name VARCHAR(100),
    quantity INT,
    price INT
);

-- サンプルデータの挿入
INSERT INTO orders (product_name, quantity, price) VALUES ('高性能ゲーミングPC', 1, 250000);
INSERT INTO orders (product_name, quantity, price) VALUES ('ワイヤレスマウス', 10, 5000);
INSERT INTO orders (product_name, quantity, price) VALUES ('4Kモニター', 2, 60000);
INSERT INTO orders (product_name, quantity, price) VALUES ('メカニカルキーボード', 5, 15000);
INSERT INTO orders (product_name, quantity, price) VALUES ('HDMIケーブル', 20, 1200);
INSERT INTO orders (product_name, quantity, price) VALUES ('PCデスク', 1, 45000);

データの挿入後の状態は以下のようになります。`AUTO_INCREMENT`（自動採番）を使用しているため、`order_id`には1から順に大きな数値が割り振られます。これが将来的に数億、数十億件になっても、BIGINTならシステムが停止することはありません。

order_id | product_name         | quantity | price
---------+----------------------+----------+--------
1        | 高性能ゲーミングPC   | 1        | 250000
2        | ワイヤレスマウス     | 10       | 5000
3        | 4Kモニター           | 2        | 60000
4        | メカニカルキーボード | 5        | 15000
5        | HDMIケーブル         | 20       | 1200
6        | PCデスク             | 1        | 45000

データベース運用の落とし穴を避けるために

多くの開発者が経験する失敗の一つに、INT型の最大値である21億件（またはUNSIGNEDの42億件）を超えてしまう「溢れ（オーバーフロー）」問題があります。有名な事例では、YouTubeの動画再生回数がINT型の範囲を超えてしまったため、急遽BIGINTへの移行が行われたことがありました。 こうした事態を未然に防ぐためには、設計段階で「このデータは指数関数的に増える可能性があるか？」を自問自答することが大切です。

• 履歴データ・ログデータ： 迷わずBIGINTを選択しましょう。
• マスターデータ（カテゴリIDなど）： INT、あるいはもっと小さなSMALLINTやTINYINTでも十分な場合があります。
• 主キー（Primary Key）： ほとんどのWebアプリケーションでは、将来の拡張性を考えてBIGINT UNSIGNED（符号なし）を採用するのが現在のトレンドです。