解决integer范围问题，核心是选对数据库类型并配合范围函数做边界校验，MySQL、PostgreSQL、SQL Server的INT范围各不相同，用错轻则报错重则数据截断。
为什么integer范围总在关键时刻掉链子
你写表结构时随手一个INT,以为万事大吉，结果用户量涨到一定规模，ID突然溢出，查询直接报错，这不是个例，相当一部分开发者在建表初期没考虑integer范围，等生产环境出问题才回头补课。
各数据库integer类型范围横向对比
不同数据库对整数类型的定义有差异,选型前先看这张表：
| 数据库 | 类型 | 字节数 | 范围 |
|---|---|---|---|
| MySQL | TINYINT | 1 | -128~127 |
| MySQL | SMALLINT | 2 | -32768~32767 |
| MySQL | MEDIUMINT | 3 | -8388608~8388607 |
| MySQL | INT | 4 | -2147483648~2147483647 |
| MySQL | BIGINT | 8 | -9.22×10¹⁸~9.22×10¹⁸ |
| PostgreSQL | SMALLINT | 2 | -32768~32767 |
| PostgreSQL | INTEGER | 4 | -2147483648~2147483647 |
| PostgreSQL | BIGINT | 8 | -9.22×10¹⁸~9.22×10¹⁸ |
| SQL Server | SMALLINT | 2 | -32768~32767 |
| SQL Server | INT | 4 | -2147483648~2147483647 |
| SQL Server | BIGINT | 8 | -9.22×10¹⁸~9.22×10¹⁸ |
| Oracle | NUMBER(10) | 自定义 | 最大支持38位精度 |
MySQL还有个特殊点,INT支持UNSIGNED属性，范围变成0~4294967295，但代价是负数存不进去，PostgreSQL没有这个属性，但可以用DOMAIN或CHECK约束模拟。
哪些场景最容易踩中integer范围天花板
- 自增主键：一张表数据量超过21亿条，INT主键必然溢出，论坛、日志、订单表是高发区
- 时间戳存储：用INT存Unix时间戳，2038年1月19日会触发32位溢出，这就是著名的2038年问题
- 金额计算的中间值
：单价乘以数量再累加，如果中间结果超过INT范围，MySQL在计算过程中就会报错
- IM消息ID：微信这类量级的消息表，一天可能产生千万级记录，BIGINT是起步配置
MySQL int范围超出后为什么报错
你在MySQL里执行INSERT,数据超过INT范围，直接报Out of range value for column，原因在于MySQL默认开启严格模式，超出范围直接拒绝写入，而不是像老版本那样自动截断成边界值。
严格模式和非严格模式的实战差异
MySQL 5.7以后默认开启严格模式，插超出范围的值会报错，如果你把SQL_MODE改成非严格模式，插入2000000000到INT字段，实际会写入2147483647，安静地截断，这种静默错误比报错可怕得多。
sql_mode的检查和修改路径
-- 查看当前模式 SELECT @@sql_mode; -- 临时关闭严格模式 SET sql_mode = ''; -- 永久修改需要改my.cnf配置文件，在[mysqld]段加 sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
行业共识认为,严格模式必须开启，截断数据造成的业务逻辑错误比报错难排查十倍。
数据库范围函数到底怎么用
范围函数不是MySQL专属,PostgreSQL的GENERATE_SERIES、SQL Server的窗口函数、甚至Excel里的MAX/MIN都算范围函数家族，核心作用就是帮你把边界值算清楚，避免踩坑。
PostgreSQL的GENERATE_SERIES生成连续序列
这是生成测试数据的神器,直接指定范围，一次性产出连续整数。
-- 生成1到10的连续整数 SELECT FROM GENERATE_SERIES(1, 10); -- 生成偶数序列，步长为2 SELECT FROM GENERATE_SERIES(2, 20, 2);
结合integer范围校验,可以快速验证一张表是否有溢出风险：
-- 找出表里超过INT最大值的记录 SELECT id, name FROM users WHERE id > 2147483647;
MySQL的LEAST和GREATEST做边界钳制
这两个函数返回参数列表的最小值和最大值,常用于把数据锁定在安全范围内。
-- 保证结果不超过100 SELECT LEAST(price quantity, 100) FROM orders; -- 保证结果不低于0 SELECT GREATEST(price - discount, 0) FROM products;
配合CAST函数,可以提前暴露溢出风险：
-- 如果total超过INT范围，CAST会报错 SELECT CAST(SUM(amount) AS SIGNED) FROM payments;
SQL Server的窗口函数范围定位
ROW_NUMBER、RANK这些窗口函数天然和范围相关，配合OVER子句可以在指定分区内计算。
-- 按部门给员工编号，编号范围限定在部门内
SELECT name, department,
ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) AS rn
FROM employees;
超出integer范围后的补救方案
线上已经出了溢出问题,别慌，有成熟的迁移路径。
直接ALTER TABLE修改字段类型
ALTER TABLE users MODIFY COLUMN id BIGINT NOT NULL AUTO_INCREMENT;
MySQL支持原地修改,但表会锁，在业务低峰期操作，数据量过亿的表，建议用pt-online-schema-change工具，减少锁表时间。
新建表+双写迁移
适合数据量巨大、ALTER时间不可接受的场景。
- 创建新表,结构同旧表，id改为BIGINT
- 应用层开启双写,新旧表同时写入
- 用脚本按主键分批迁移旧数据,每批1000条
- 迁移完成后切换读流量到新表
- 验证数据一致性后下线旧表
分表分库，从根上降低单表数据量
按用户ID或时间维度分表,每张表的数据量控制在千万级，INT完全够用，这属于架构层面的长期解法，代价是查询逻辑变复杂。
写代码时怎么预防integer溢出
与其等出了问题再补救,不如在建表阶段就把坑填平。
主键ID直接用BIGINT，别省
现在多数公司新项目主键直接上BIGINT,理由很简单，INT的21亿上限听起来多，但UGC产品三五年就能到量级，用VARCHAR(20)存雪花ID也是常见做法，比BIGINT更灵活。
时间戳字段用DATETIME或TIMESTAMP
DATETIME占用8字节,范围是1000-01-01到9999-12-31，TIMESTAMP占用4字节但有2038年限制，MySQL 8.0.28以后TIMESTAMP的2038问题已经解决，但存量系统还是要检查。
数值运算前先估算中间值上限
-- 商品价格表和数量表关联 SELECT p.price, o.quantity, p.price o.quantity AS total FROM products p JOIN order_items o ON p.id = o.product_id;
如果price是DECIMAL(10,2)，quantity是INT，中间结果可能是DECIMAL(20,2)，直接存INT字段必然溢出，这种场景中间结果用DECIMAL，最后再CAST成需要的类型。
范围函数的高阶玩法
除了边界校验,范围函数还能做时间序列填充、数据补全、报表生成。
用GENERATE_SERIES补全缺失日期
统计每天订单量,没订单的日期是NULL，报表看着有洞，用GENERATE_SERIES生成连续日期，再LEFT JOIN订单表，缺的日期补0。
SELECT day, COALESCE(COUNT(o.id), 0) AS order_count
FROM GENERATE_SERIES('2026-01-01'::date, '2026-01-31'::date, '1 day') AS day
LEFT JOIN orders o ON o.created_at::date = day
GROUP BY day
ORDER BY day;
用BETWEEN和范围函数做区间统计
MySQL没有原生的GENERATE_SERIES,但可以用递归CTE模拟：
WITH RECURSIVE seq AS (
SELECT 1 AS n
UNION ALL
SELECT n + 1 FROM seq WHERE n < 10
)
SELECT FROM seq;
网上有大量这类写法,本质是拿递归CTE当数字表用，这类技巧在复杂报表场景出镜率很高。
Q&A：integer范围常见问题
TINYINT和INT怎么选，选错了有影响吗
TINYINT只占1字节,适合存状态值、布尔值、小范围枚举，比如性别、订单状态，存主键或用户ID是典型的不合适，21亿数据量用INT，超过就得改结构，改结构就要锁表，选类型前先想清楚这个字段未来三年的量级，而不是当前量级。
MySQL int范围超出为什么插入NULL而不是报错
非严格模式下,超出范围的整数会变成边界值，不是NULL，如果插入的是字符串且无法转为数字，SQL_MODE里没有STRICT_TRANS_TABLES时，会变成0并产生警告，开启严格模式后，这类问题会直接报错，不会静默写入脏数据。
数据库的integer范围函数能替代应用层校验吗
不能,范围函数是数据库层面的兜底，应用层校验是第一道防线，数据从API进来，先在后端校验数值范围，再考虑数据库函数兜底，两层校验都做，才能保证数据质量和系统稳定，数据库函数适合做批量数据迁移、报表计算这类场景，不适合替代业务逻辑层的参数校验。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/integer%e8%8c%83%e5%9b%b4%e4%b8%8e%e8%8c%83%e5%9b%b4%e5%87%bd%e6%95%b0%e6%9c%89%e4%bb%80%e4%b9%88%e5%8c%ba%e5%88%ab%ef%bc%8c%e6%80%8e%e4%b9%88%e7%94%a8%ef%bc%9f/
