本质是整型溢出导致编号循环复用，需从生成逻辑（检查int/AtomicInteger/雪花算法截断）、存储类型（Java int与DB INT SIGNED/BIGINT匹配）、校验机制（唯一索引是否生效）三方面系统排查。
这个问题本质是整型溢出引发的编号循环复用，不是随机重复，而是有规律地“绕回”到已用过的值。关键要从生成逻辑、存储类型、校验机制三方面系统排查。
检查优惠券编号生成算法是否依赖int类型
很多老系统用int做自增ID或时间戳+序列组合，一旦累计发券超21.47亿（Integer.MAX_VALUE），下一次就会变成Integer.MIN_VALUE（-2147483648），迅速撞上历史编号。
- 翻代码确认生成处是否用了
int或Integer——尤其注意AtomicInteger、int++、(int)System.currentTimeMillis()这类写法 - 如果用雪花算法（Snowflake），检查workerId和sequence位数是否被硬编码为int，导致整体结果被截断
- 临时加日志：在生成编号后立刻打印原始值和最终存库值，对比是否发生隐式截断
核对数据库字段类型是否匹配Java端定义
Java用int，但数据库字段如果是INT UNSIGNED或BIGINT，看似能存更大数，实际Java端溢出后传入负数，数据库可能自动转成大正数（如MySQL把-1存成4294967295），造成逻辑错乱。
- 查建表SQL，确认字段类型是
INT SIGNED（范围±21.47亿）还是BIGINT - 用
SELECT MIN(id), MAX(id) FROM coupon看当前编号分布，若出现大量负数或接近4294967295的值，基本可判定溢出 - 检查JDBC驱动配置，确认没有开启
tinyInt1isBit=false之类影响数值解析的参数
验证唯一性约束是否真正生效
即使编号生成出错，数据库唯一索引应拦截重复插入。若没报错，说明约束缺失或被绕过。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 执行
SHOW CREATE TABLE coupon，确认id字段有UNIQUE KEY或PRIMARY KEY - 检查DAO层是否用了
INSERT IGNORE或ON DUPLICATE KEY UPDATE，这些会静默吞掉冲突，掩盖问题 - 模拟溢出场景：手动插入一条
id = 2147483647，再触发一次生成逻辑，观察是否抛SQLException（SQLState: 23000）
落地修复建议
短期止血优先升级类型，长期需解耦编号生成与业务逻辑。
- Java端将编号类型改为
long，对应数据库字段改为BIGINT，并同步更新所有DTO、Mapper、Redis缓存序列化逻辑 - 停用自增ID，改用分布式ID生成器（如TinyID、Leaf），确保全局唯一且不依赖单点计数器
- 增加上线前校验：启动时读取当前最大编号，若>20亿则拒绝启动，并告警提示迁移风险
- 对存量数据做一次扫描：
SELECT id, COUNT(*) c FROM coupon GROUP BY id HAVING c > 1，定位已发生的重复记录
不复杂但容易忽略。核心就是守住“类型一致”和“溢出可见”两条线——只要编号生成、传输、存储、校验全程不出现int，问题就不会复发。
