Django+PostgreSQL中自定义10位格式主键是否明智？扩容有性能风险吗？

我正在为某应用开发Django后端，希望实体的primary key满足以下条件：
一是长度固定为10字符，便于读写及口头分享；
二是遵循固定格式：

• 前2位：实体编码（例如"US"代表User记录、"TO"代表主题、"BO"代表书籍等），可快速识别ID所属实体；
• 第3-4位：记录创建年份的后两位（如'24'、'23'等）；
• 剩余6位：随机生成的字母数字字符。

我编写了如下生成ID的代码：

def auto_increment_id():
    alphanumeric_chars = string.ascii_letters + string.digits
    last_chars = ''.join(random.choice(alphanumeric_chars) for _ in range(6))
    user_id = 'US' + str(datetime.date.today().year)[2:] + str(last_chars)
    return user_id

并在User模型中进行了如下配置：

class User(models.Model):
    id = models.CharField(max_length=10, primary_key=True,
                          default=auto_increment_id, editable=False)

我的问题是：随着业务扩容，该设置是否会引发性能问题或其他问题？此方案是否合理？

分析与解答 #

一、方案的合理性 #

这个方案有几个实用的优点：

• 可读性强：前缀直接标识实体类型，年份段能快速判断记录创建时间，口头分享或手动核对时很方便；
• 长度友好：10字符的长度既不会太长难记，也不会太短导致冲突概率飙升；
• 冲突概率低：6位大小写字母+数字的组合数约为5.68亿，单年内单实体的记录量只要不接近这个量级，重复概率可以忽略。

二、潜在的问题与风险 #

1. 主键冲突隐患

当前代码没有重复校验逻辑，一旦随机生成的ID已存在，Django会直接抛出主键冲突异常，导致数据保存失败。而且random模块生成的是伪随机数，极端场景下重复概率会比理论值高。

2. 数据库性能损耗

• 索引效率：字符型主键相比Django默认的整数型主键（AutoField），索引存储体积更大，查询、排序时的比较速度更慢，数据量越大，关联查询（比如外键关联）的性能差异越明显；
• 写入性能：如果加上重复校验逻辑，数据量庞大时，校验存在性的查询次数会增加，拖慢写入速度。

3. 年份溢出问题

用年份后两位的设计，到2100年会出现"00"，和2000年的ID前缀重复，虽然是几十年后的问题，但长期运行的应用会留下隐患。

4. 外键关联的不便

其他模型用这个字符型主键做外键时，外键字段也会是字符类型，相比整数外键，存储占用更大，关联查询的效率也会降低。

三、优化建议 #

1. 强制添加重复校验：生成ID后检查数据库是否已存在，重复则重新生成，直到得到唯一值：

import string
import secrets
from datetime import date
from django.apps import apps

def auto_increment_id():
    alphanumeric_chars = string.ascii_letters + string.digits
    prefix = 'US' + str(date.today().year)[2:]
    User = apps.get_model('your_app_name', 'User')  # 替换为你的应用名
    while True:
        last_chars = ''.join(secrets.choice(alphanumeric_chars) for _ in range(6))
        user_id = prefix + last_chars
        if not User.objects.filter(id=user_id).exists():
            return user_id

（改用secrets模块生成加密安全的随机数，进一步降低重复概率）

2. 优化年份标识：如果担心年份溢出，可以把第3-4位改成"24"代表2024、"30"代表2100，用第一位数字标识世纪（2=20xx，3=21xx），或者直接用年份后三位（但要调整整体字符长度）。

3. 性能优先的折中方案：如果业务对性能要求极高，可以保留整数型主键，额外添加entity_code（实体编码）、create_year（创建年份）两个字段，既保证数据库性能，又能通过这两个字段实现原需求中的识别功能。

内容的提问来源于stack exchange，提问作者Ragav Y