Postgres 11中带前缀的KSUID作为主键是否会影响性能？

针对你提到的以带资源类型前缀的KSUID（示例值order_0ujsswThIGTUYm2K8FjOOfXtY1K）为B树主键、访问模式以精确匹配为主的场景，以下是对应问题的实际结论：

1. 带前缀写法是否会抵消KSUID的缓存局部性、高插入速度优势？ #

不会完全抵消，绝大多数业务场景下完全感知不到差异。
KSUID的核心性能优势来自自身前4字节携带时间戳、新生成的值排序上彼此接近，插入B树时只会集中在索引尾部写入，不会像完全随机的UUID那样把写入分散到整个索引的各个数据页打穿缓存。只要你单张表的主键前缀是固定的——比如订单表所有主键全是order_开头，不会混进其他资源类型的前缀——所有主键值前几位都是完全相同的，后面跟着的KSUID部分依然保持时间有序特性，原有的缓存局部性、高写入吞吐优势基本能完整保留。
唯一的额外开销只有两点：

• 每个主键值多占了前缀对应几个字节的存储空间
• 做字符串等值比较时多比对了前面几个固定相同的字符
  这个级别的开销只有单表数据量到十亿级以上才可能测出可量化的差异，普通业务系统完全不用考虑。

2. 是否更适合存储不带前缀的纯KSUID（即0ujsswThIGTUYm2K8FjOOfXtY1K）？ #

没有绝对最优解，完全取决于业务使用场景：

• 如果主键只在数据库内部流转，不会出现在接口返回、日志、前端页面等对外暴露的位置，存不带前缀的纯KSUID确实更省空间，理论性能也更好，是更优选择。
• 如果主键需要透出到业务链路里，带前缀的写法带来的业务价值远大于那点微乎其微的性能损耗：排查线上问题时扫一眼ID就知道对应的资源类型，不用拿着ID翻好几个库表确认；跨系统调用时也能靠前缀快速做参数合法性校验，避免把用户ID传到订单查询接口这类低级错误。
  要是你实在纠结那点性能开销，又想要前缀的可读性，可以用生成列方案：表主键存纯KSUID值，额外加一个自动拼接前缀的生成列专门做对外透出，不过说实话99%的业务系统做这个优化都是浪费时间，投入产出比极低。

3. 带前缀取值对B树索引的影响 #

影响完全取决于前缀的使用方式，核心分两种情况：

• 单表前缀固定：同一张表所有主键的前缀完全一致时，对B树几乎没有负面影响。B树是逐字节比较键值排序的，前面完全相同的固定前缀相当于给所有键加了个公共头，根本不会打乱后面KSUID本身的有序性，不管是精确匹配查询，还是利用KSUID时间特性做的范围查询，效率和存纯KSUID没有可感知的差别。
• 单表前缀不固定：比如用一张全局资源表混存order_、user_、pay_等不同前缀的ID，那KSUID本身的时间有序性就会被前缀打散：哪怕两个不同前缀的KSUID是同一时间生成的，排序时也会因为前缀不同被分到B树的不同分支，写入时会分散到索引的不同数据页，这时候KSUID原有的缓存局部性优势会打折扣，写入吞吐大概会比固定前缀/纯KSUID的方案低两成左右，同样只有数据量到千万级以上这个差异才会被感知到。

你提到网上大部分相关讨论都围绕LIKE前缀查询场景展开，那种场景下固定前缀本身是可以被B树索引利用做范围扫描的，不过你是纯精确匹配的访问模式，这个特性对你没有实际影响。

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