使用字典序字符串作为主键的性能影响（PostgreSQL及主流DBMS）

一、YYYYMMDD_随机字符结构主键的读性能损耗 #

针对你给出的场景（仅等值查询、读远多于写、1000万条记录、主键长度15-30字符），性能损耗主要集中在以下两点：

• 索引存储与IO开销：字符串主键的体积是整数主键（4-8字节）的3-7倍，对应B树索引的总大小会大幅增加。1000万条记录的情况下，字符串主键索引可能占用数GB空间，而整数主键索引仅需几百MB。这会直接降低缓存命中率——相同内存容量下能缓存的索引条目更少，更多读请求需要触发磁盘IO，这是最显著的性能瓶颈。如果内存能完全容纳整个索引，这个差异会被大幅缩小。
• CPU比较开销：字符串等值查询的CPU消耗略高于整数，但在PostgreSQL中这个差异极小，只有在极端高频的查询场景下才会显现，通常不是主要影响因素。

由于你仅做等值查询，主键前半部分的日期有序性不会带来额外优势，但也不会产生负面作用——B树索引的等值查询效率只和索引条目大小、缓存命中情况相关，和键的顺序无关。

结论：若内存充足，读性能和整数主键差异不大；若内存不足，磁盘IO增加会导致读性能下降20%-50%甚至更多，具体取决于缓存命中率。

二、附加问题：有序前缀+随机后缀主键的写入性能影响（插入/删除频率相当） #

当主键前半部分为当前时间（整体按日期有序、单日内部随机），且插入与删除频率相近时，写入性能会受到以下影响：

• 局部热点与页分裂：每日的主键前缀固定，插入操作会集中在B树索引的局部区域（对应当日前缀的索引页），导致该区域的索引页频繁被修改，页分裂概率升高。不过单日内部是随机后缀，不会像自增主键那样持续在页尾插入，所以热点程度比完全自增主键低。
• 索引膨胀风险：随机位置的删除会在索引各个区域产生空洞，而插入集中在局部区域，空洞的复用效率较低，长期运行后会导致索引膨胀，进一步增加写入时的IO开销。
• 锁竞争：局部热点区域的频繁修改会增加索引页的锁竞争，导致插入操作的等待时间变长。

整体来看，这种结构的写入性能比完全随机字符串主键稍差，但优于完全自增主键。如果插入和删除长期维持相当频率，需要定期重建索引来缓解膨胀问题，避免性能持续下降。

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