开发商品售卖类应用时，slug应设为主键ID还是全局二级索引

99%的用户自定义挂牌场景下，不要将slug设为主键，优先选有序UUID/自增ID作为主键，slug设置为带唯一约束的二级普通索引

为什么不推荐把slug当主键 #

• slug是可变业务字段：用户修改商品标题、运营统一调整slug格式的需求太常见了，如果slug是主键，所有关联表（订单、收藏、浏览记录等）的外键都需要同步更新，大部分数据库修改主键的操作会触发表重写，性能开销极高，甚至导致服务不可用。
• slug长度不可控：用户输入的标题长度没有上限，生成的slug可能长达数十甚至上百字符，作为主键会让所有关联表的外键体积同步膨胀，索引占用空间大幅提升，反而降低查询效率。
• 冲突处理逻辑复杂：用户发布完全相同的商品时，需要给重复的slug加后缀（如商品名-2、商品名-3），如果slug是主键，会把冲突处理逻辑完全耦合到主键生成流程中，后续扩展性极差。

踩坑预警：之前见过团队把slug当主键，后来要求全站商品slug统一加品类前缀，主表刷了3小时不说，关联的12张业务表全要同步更新，差点导致全站服务宕机。

主键选型怎么定 #

根据你用的数据库特性选就行：

• 如果用MySQL InnoDB这类带聚簇索引的引擎：优先选**UUIDv7（有序UUID）**或者短自增ID。自增ID占用空间最小（仅8字节），所有关联表存这个外键的索引体积小、查询快，但缺点是ID连续可被爬虫批量遍历；UUIDv7自带时间有序性，插入性能和自增ID接近，也不会暴露商品总数量，是兼顾性能和隐私的最优解。不要选UUIDv4这类无序UUID，会导致聚簇索引频繁页分裂，写入性能大幅下降。
• 如果用PostgreSQL这类默认堆表的数据库：普通无序UUID（UUIDv4）也可以用，性能影响非常小。

slug索引的最优配置 #

• 直接给slug字段加唯一普通二级索引即可，单条商品的查询走二级索引找主键再回表的开销，对于绝大多数业务场景来说完全感知不到，和直接用slug当主键的查询性能几乎没有差别。
• 如果你的slug普遍很长，可以给索引指定前缀长度（比如验证过前20个字符就能保证全局唯一），进一步压缩索引体积，提升查询效率。

唯一例外的场景 #

只有当你的商品slug完全满足「全局唯一、长度固定、生成后永不修改」三个前提时，才可以考虑把slug当主键——比如卖标准化编码的工业零件，slug就是出厂固定的SKU编码，这种场景下用slug当主键能省一次回表开销。但你现在是用户自由创建售卖挂牌，完全不满足这个前提，没必要冒这个险。

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