Postgres数据库feed表主键ID命名模式选择的优缺点咨询

安全阿岳

2026-10-7

这种ID命名模式的弊端主要有以下几点：

主键存储成本上升，索引性能下降
原25位varchar ID加前缀后长度增加到30位以上，feed表通常数据量极大，更长的主键会让主键索引的磁盘、内存占用明显升高，查询时IO开销更大，整体读写性能都会受到影响。
破坏主键原子性，额外增加计算开销
主键同时存储了类型和关联ID两个信息，你需要提取其中任意一个的时候都要做字符串拆分，不管是在应用层还是数据库层执行拆分都会消耗额外算力。如果需要按动态类型筛选数据，用LEFT(id, 5) = 'user:'这类语法无法命中主键索引，反而会导致全表扫描，比单独加feed_type字段的方案慢得多，完全达不到你减少数据库请求的初衷。
阻碍跨表关联
带前缀的feed ID无法直接和用户、群组表的纯ID做关联查询，每次关联都需要先做字符串拆分提取原始ID，会大幅降低多表查询的效率，如果后续有其他表需要关联feed主键，这个问题会更突出。
扩展性差，容易引发业务bug
如果后续新增其他类型的动态（比如活动、话题），不同前缀的长度不一致（比如activity:比user:长5个字符），会导致字符串拆分逻辑需要兼容多种长度，非常容易出逻辑错误。如果一开始设置的varchar长度没有预留足够空间，还需要执行改表操作调整字段长度，对于大表来说改表成本极高。
你的核心需求完全有更优的替代方案
想要减少数据库往返完全不需要改造主键：新增一个feed_type字段存储动态类型的枚举值，再搭配现有的userId、groupId等关联ID字段，查询feed的时候直接把这几个字段一并返回即可，不需要额外的数据库请求，同时也不会有上述各种问题。