MySQL整数类型详解：TINYINT、INT与BIGINT实战指南-代码聚汇网

MySQL整数类型详解：TINYINT、INT与BIGINT实战指南

不吃章鱼烧·2026-08-07·阅读 24 GEO检测（免费）

MySQL整数类型TINYINT

|难度：普通|阅读约 14 分钟

1. 为什么需要了解MySQL整数类型？

作为关系型数据库中最基础的数据类型，整数类型的选择直接影响着数据存储效率、查询性能和系统稳定性。在实际项目中，我见过太多因为数据类型选择不当导致的性能问题——从存储空间浪费到索引失效，甚至出现数据溢出的生产事故。

MySQL提供了五种整数类型：TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT。它们的主要区别在于存储空间和数值范围。今天我们就重点剖析最常用的TINYINT、INT和BIGINT这三种类型，通过实际案例说明它们的使用场景和避坑要点。

提示：在MySQL 8.0版本中，整数类型的最大最小值范围与早期版本保持一致，但内部存储机制有所优化。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. TINYINT：小身材大用处的迷你整数

2.1 基本特性与存储原理

TINYINT是MySQL中最小的整数类型，仅占用1字节（8位）存储空间。其数值范围分为有符号和无符号两种：

有符号：-128 到 127
无符号：0 到 255

这种紧凑的存储特性使其成为状态标志、开关选项等场景的理想选择。例如用户性别字段：

sql复制CREATE TABLE users (
    gender TINYINT UNSIGNED COMMENT '0-未知 1-男 2-女'
);

2.2 实际应用场景解析

在电商系统中，TINYINT非常适合存储订单状态：

sql复制CREATE TABLE orders (
    status TINYINT UNSIGNED NOT NULL DEFAULT 0 
        COMMENT '0-待支付 1-已支付 2-已发货 3-已完成 4-已取消'
);

但要注意一个常见陷阱：布尔值的存储。虽然MySQL没有原生BOOLEAN类型，但BOOL和BOOLEAN实际上是TINYINT(1)的别名。这意味着：

sql复制-- 以下两种定义本质相同
is_active BOOLEAN DEFAULT FALSE
is_active TINYINT(1) DEFAULT 0

注意：使用TINYINT作为枚举值时，务必添加COMMENT说明每个数值的含义，否则时间久了连开发者自己都会忘记各数字代表的业务含义。

3. INT：平衡型选手的全面剖析

3.1 存储结构与性能表现

INT（或称INTEGER）占用4字节（32位）存储空间，其数值范围：

有符号：-2,147,483,648 到 2,147,483,647
无符号：0 到 4,294,967,295

这是MySQL中最常用的整数类型，适合存储用户ID、商品数量等常规数值。在InnoDB引擎中，INT作为主键时有特殊的优化：

sql复制CREATE TABLE products (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    stock INT UNSIGNED NOT NULL DEFAULT 0
);

3.2 宽度修饰符的误解与真相

很多开发者对INT(11)中的11存在误解——这并非限制存储的数值位数，而是显示宽度（zerofill时有用）。实际存储范围由数据类型本身决定：

sql复制-- 以下两个字段实际存储能力完全相同
id INT(11) UNSIGNED
id INT(8) UNSIGNED

在金融系统中处理金额时（单位：分），INT UNSIGNED可以完美表示0-42亿的金额范围，相当于4.2亿元。这是比使用DECIMAL更高效的方案：

sql复制-- 金额存储方案对比
amount DECIMAL(10,2)  -- 存储空间8字节
amount INT UNSIGNED   -- 存储空间4字节（单位：分）

4. BIGINT：应对海量数据的终极方案

4.1 超大规模数据处理

BIGINT占用8字节（64位）存储空间，其数值范围：

有符号：-9,223,372,036,854,775,808 到 9,223,372,036,854,775,807
无符号：0 到 18,446,744,073,709,551,615

在需要处理Twitter级别的用户量或物联网海量设备时，BIGINT是唯一选择：

sql复制CREATE TABLE iot_devices (
    device_id BIGINT UNSIGNED PRIMARY KEY,
    timestamp BIGINT UNSIGNED COMMENT 'Unix时间戳，毫秒精度'
);

4.2 自增主键的隐患与解决方案

使用BIGINT自增主键时要注意：当达到最大值时继续插入会导致错误。分布式系统推荐使用雪花算法（Snowflake）生成ID：

sql复制CREATE TABLE distributed_table (
    id BIGINT UNSIGNED PRIMARY KEY DEFAULT 
        ((UNIX_TIMESTAMP() << 22) | (SERVER_ID << 12) | (NEXT_VALUE % 4096)),
    ...
);

在时序数据库中处理纳秒级时间戳时，BIGINT也是不二之选：

sql复制CREATE TABLE metric_data (
    ts BIGINT COMMENT '纳秒时间戳',
    value DOUBLE,
    PRIMARY KEY (ts)
) ENGINE=InnoDB;

5. 类型选择实战指南

5.1 性能与存储的平衡艺术

通过一个实际测试案例说明存储空间差异：

sql复制-- 测试表结构
CREATE TABLE size_test (
    id INT AUTO_INCREMENT PRIMARY KEY,
    tiny TINYINT,
    normal INT,
    big BIGINT
);

-- 插入100万条数据后查看表大小
-- TINYINT：约6MB
-- INT：约11MB 
-- BIGINT：约21MB

5.2 类型转换的隐藏成本

隐式类型转换可能导致索引失效：

sql复制-- 假设mobile是VARCHAR但存储数字
SELECT * FROM users WHERE mobile = 13800138000; -- 全表扫描
SELECT * FROM users WHERE mobile = '13800138000'; -- 使用索引

在JOIN操作中类型不匹配也会引发性能问题：

sql复制-- 表A的user_id是INT，表B的user_id是BIGINT
SELECT * FROM table_a JOIN table_b ON table_a.user_id = table_b.user_id;
-- 类型转换导致无法使用索引

5.3 监控与优化建议

通过INFORMATION_SCHEMA监控数据类型使用情况：

sql复制SELECT 
    TABLE_NAME,
    COLUMN_NAME,
    DATA_TYPE,
    COLUMN_TYPE,
    COLUMN_COMMENT
FROM 
    INFORMATION_SCHEMA.COLUMNS
WHERE 
    DATA_TYPE IN ('tinyint', 'int', 'bigint')
ORDER BY 
    TABLE_NAME, ORDINAL_POSITION;

在数据仓库建设中，推荐使用最小的适用类型。例如用户年龄使用TINYINT UNSIGNED足够（0-255岁），而不要直接使用INT。

6. 特殊场景深度解析

6.1 位运算的高效应用

TINYINT非常适合存储多个布尔标记的组合：

sql复制-- 使用单个TINYINT存储8个开关状态
CREATE TABLE user_settings (
    user_id INT,
    settings TINYINT UNSIGNED COMMENT '位0:接收邮件 位1:接收短信...'
);

-- 检查第0位是否开启
SELECT * FROM user_settings WHERE settings & 1;

6.2 时间戳存储的进阶方案

处理毫秒/微秒级时间戳时，BIGINT比DATETIME更灵活：

sql复制-- 存储毫秒时间戳并转换为可读格式
SELECT 
    event_id,
    FROM_UNIXTIME(ts/1000) AS datetime,
    ts % 1000 AS milliseconds
FROM events;

6.3 分布式ID生成策略

除了雪花算法，还可以考虑这些BIGINT ID生成方案：

sql复制-- UUID转数字（损失部分精度）
SELECT CONV(REPLACE(UUID(), '-', ''), 16, 10) INTO @bigint_id;

-- 数据库序列方案
CREATE TABLE id_sequence (
    stub CHAR(1) PRIMARY KEY,
    id BIGINT UNSIGNED NOT NULL
) ENGINE=InnoDB;

7. 数据类型变更的实战经验

7.1 安全变更数据类型的方法

从INT升级到BIGINT的正确姿势：

sql复制-- 步骤1：创建新表
CREATE TABLE new_table LIKE old_table;
ALTER TABLE new_table MODIFY id BIGINT UNSIGNED AUTO_INCREMENT;

-- 步骤2：数据迁移（分批进行）
INSERT INTO new_table SELECT * FROM old_table WHERE id BETWEEN 1 AND 100000;
...

-- 步骤3：原子切换
RENAME TABLE old_table TO old_table_backup, new_table TO old_table;

7.2 变更前的风险评估

检查外键约束和索引情况：

sql复制SELECT 
    TABLE_NAME, COLUMN_NAME, 
    CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME
FROM 
    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE 
    REFERENCED_TABLE_NAME = 'your_table';

7.3 在线变更工具推荐

对于大表变更，推荐使用这些工具：

pt-online-schema-change
gh-ost
Facebook的OnlineSchemaChange

这些工具可以在不锁表的情况下完成数据类型变更，对生产环境影响最小。