Django模型UUID主键使用场景、优劣及PostgreSQL默认主键溢出问题

嘿，这个问题问到点子上了！我在Django项目里踩过不少主键选择的坑，来给你好好梳理梳理。

一、适合用UUID作为主键的场景 #

• 分布式系统/多数据源合并：如果你的系统是分布式部署，或者经常需要把多个数据库、外部数据源的数据合并到一起，UUID的全局唯一性能完美避免主键冲突——完全不用像自增ID那样费劲协调起始值、步长，或者处理冲突数据。
• URL/接口安全需求：如果你的API或页面直接用主键暴露资源（比如/orders/123/），自增ID很容易被恶意爬虫遍历，把所有数据扒走。换成UUID的话，/orders/550e8400-e29b-41d4-a716-446655440000/这种串几乎不可能被猜中，能给数据隐私多添一层保障。
• 频繁数据迁移/导入：经常需要从外部批量导入数据到Django模型？UUID不用操心新导入数据的ID会不会和现有库的ID撞车，省了一大堆处理自增ID冲突的麻烦。
• 提前生成主键的业务场景：有些业务需要在数据存入数据库之前就拿到主键（比如生成订单时先返回订单ID，再异步写入数据库），UUID可以直接在应用层生成，不用依赖数据库的自增机制，灵活很多。

二、UUID字段的优缺点 #

优点 #

• 全局唯一：这是UUID最核心的优势，分布式场景下完全不用担心主键重复，省掉了很多跨节点协调的工作量。
• 无状态生成：不需要和数据库交互就能生成主键，适合离线操作、异步任务这类不能实时访问数据库的场景。
• 隐私安全：避免自增ID带来的遍历风险，防止恶意用户通过遍历ID获取所有资源。

缺点 #

• 存储与索引成本更高：UUID是36位字符串（如果存二进制是16字节），而PostgreSQL的bigint主键只有8字节。数据量越大，UUID占用的存储空间和索引空间就越多，查询性能理论上会比整数主键差一些——千万级以上数据量时这个差异会比较明显。
• 可读性差：调试的时候看一串UUID肯定不如看12345这种整数直观，排查问题时会稍微麻烦点。
• 无序UUID的写入性能问题：默认的UUIDv4是随机生成的，插入数据时会导致数据库索引频繁分裂，影响写入速度。不过现在Django支持UUIDv7（带时间戳的有序UUID），用UUIDField(default=uuid.uuid7)就能缓解这个问题。

三、何时用UUID做主键，何时用默认主键？ #

优先选UUID的情况 #

• 符合上面提到的分布式部署、安全需求、频繁数据导入、提前生成主键的场景。
• 业务对性能没有极致要求，或者数据量在百万级及以下（这个量级下UUID的性能影响几乎可以忽略）。

优先选默认主键的情况 #

• 单数据库系统，不需要和外部数据源合并，业务逻辑简单。
• 对读写性能要求极高，尤其是数据量达到千万级以上时，整数主键的索引效率和查询速度优势会非常明显。
• 看重调试和维护的便捷性，希望主键直观好记，方便排查问题。

四、PostgreSQL默认主键会不会超出最大值？ #

放心，正常业务场景下绝对不会！

Django 3.2及以上版本默认的主键是BigAutoField，对应PostgreSQL的bigint类型，取值范围是**-9223372036854775808到9223372036854775807**，也就是大约9万亿亿条数据。就算你每秒插入100万条数据，也要差不多292亿年才能用完这个数值——这显然是不可能的。

如果是老版本Django用的AutoField（对应PostgreSQL的int类型），取值范围是-2147483648到2147483647，大约20亿条数据。除非你的表数据量真的接近20亿，否则也完全不用担心溢出；真到那一步，换成BigAutoField或者UUID就好。

内容的提问来源于stack exchange，提问作者Paul R