ThinkPHP不处理数据库主键溢出，根本解决需建表时用BIGINT而非INT，已溢出则改表或切换雪花ID/UUID；分表不能防溢出，须全面检查所有增长型数字字段。
ThinkPHP 本身不处理数据库主键溢出问题——它只是 ORM 层，真正决定 ID 是否溢出的是底层数据库（如 MySQL 的 INT 或 BIGINT 类型）和你的建表逻辑。一旦发生自增 ID 溢出，不是框架能“修复”的，而是必须提前规避或紧急切换策略。
MySQL 自增字段已溢出的典型错误
你看到的报错通常是数据库返回的，例如：
ERROR 1467 (HY000): Failed to read auto-increment value from storage engine
或更隐蔽的表现：新记录插入失败、ID 突然变成 1（INT UNSIGNED 溢出回绕）、甚至静默截断（如 INT 存 2147483648 变成 -2147483648）。
立即学习“PHP免费学习笔记（深入）”；
这不是 ThinkPHP 的 bug，而是建表时类型选小了 + 数据量真上来了。
建表阶段就该用 BIGINT 而非 INT
这是最简单也最有效的预防手段。别等溢出才改——现在就改。
- MySQL
INT最大值是2147483647（有符号）或4294967295（无符号），约 42 亿条记录；而BIGINT是9223372036854775807，够用几十年 - ThinkPHP 迁移或建表时，明确指定类型：
$this->table('user')->addColumn('id', 'biginteger', ['identity' => true, 'unsigned' => true])->create(); - 已有表升级（务必先备份）：
ALTER TABLE `user` MODIFY `id` BIGINT UNSIGNED AUTO_INCREMENT;
注意：如果当前id已接近INT上限，执行前需确认目标BIGINT能容纳现有最大值（基本都满足）
已溢出且无法停机改表？用 UUID 或雪花 ID 替代自增
当线上表已爆、DBA 不允许锁表、又急需继续写入时，就得绕开自增机制。
ThinkPHP 6+ 支持自定义主键生成，无需改数据库结构：
- 关闭自增：
protected $autoWriteTimestamp = false; // 避免干扰 protected $pk = 'id'; protected $sequence = null; // 显式禁用自增序列
- 写入前手动赋值（推荐雪花 ID）：
use think\facade\Db; use think\snowflake\Snowflake; <p>$id = (new Snowflake())->id(); $user = ['id' => $id, 'name' => 'xxx']; Db::name('user')->insert($user); - 或用 UUID（字符串主键，注意索引效率）：
use think\facade\Db; use think\helper\Str; <p>$id = Str::uuid(); Db::name('user')->insert(['id' => $id, 'name' => 'xxx']);
⚠️ 注意：改用 UUID 后，ORDER BY id DESC 失去时间序优势；雪花 ID 虽有序，但需确保机器 ID/数据中心 ID 配置正确，否则可能重复。
分表或分库不是主键方案，别本末倒置
有人一提“大数据”就想到分库分表，但这是解决查询/写入性能瓶颈的，不是防 ID 溢出的。哪怕你分 1024 张表，每张表用 INT，照样会在某张子表上溢出。
真正要做的只有两件确定的事：把主键类型升到 BIGINT，在业务层生成全局唯一 ID 时选对算法。其他所有“优化”都是锦上添花，不是救命稻草。
最容易被忽略的一点：很多项目用 tinyint 或 smallint 存状态、类型字段，这些也可能悄悄溢出——检查所有带 AUTO_INCREMENT 或语义上会增长的数字字段，不只看 id。
