Postgres多节点复制场景下员工ID不连续是否合理？求专业判断

厂商的解释部分可信，但无法完全解释你遇到的极端间隙情况。

Postgres序列跳号的常见原因 #

• 多节点复制+序列缓存：Postgres序列默认会预分配一段编号（缓存）给每个节点，避免跨节点频繁同步。若节点下线或未用完缓存，预分配编号会被丢弃导致跳号，但默认缓存值通常为1或10，不会直接造成数百个编号的巨大间隙。
• 崩溃恢复：数据库崩溃重启时，为保证序列唯一性，会从WAL记录的最后序列值+缓存值开始，跳过中间未使用的编号，单次崩溃的跳号范围一般和缓存大小相关，不会出现极端间隙。
• 其他潜在原因：
  • 程序逻辑错误：显式调用nextval()生成ID后，未执行插入操作就放弃
  • 序列被手动修改：人为执行ALTER SEQUENCE ... SET START WITH调整过起始值
  • 批量生成ID后未使用：比如批量创建员工/承包商的逻辑中，生成了ID但未完成最终写入

其他模块ID连续的原因 #

客户、联系人等模块ID连续，说明这些模块的序列大概率满足以下条件之一：

• 设置了无缓存的序列（CREATE SEQUENCE ... CACHE 1），每个ID都需同步主节点确认，牺牲少量性能换连续性
• 仅在单节点处理写入，未部署多节点复制架构
• 程序逻辑严格，不存在生成ID后放弃插入的情况

对你场景的具体判断 #

ID达570但仅对应110条记录的极端间隙，单纯用多节点复制或崩溃恢复的默认行为无法完全解释，更可能是以下组合原因：

1. 员工/承包商模块的序列设置了超大缓存值（比如CACHE 100及以上），加上多节点频繁上下线，导致大量预分配编号被丢弃
2. 程序存在逻辑漏洞，频繁生成ID但未完成插入，累积了大量无效的序列消耗
3. 厂商曾手动调整过该序列的起始值，导致ID直接跳变

后续建议 #

• 要求厂商提供该序列的具体配置（执行SELECT * FROM pg_sequence WHERE seqrelid = '目标序列名'::regclass;），查看缓存值（seqcache字段）和历史修改记录
• 要求厂商排查程序日志，确认是否存在大量生成ID但未插入的异常情况
• 若对ID连续性有硬性要求，可要求厂商将该序列改为CACHE 1，或使用Postgres 10+的IDENTITY列（GENERATED ALWAYS AS IDENTITY），在多节点架构下也能控制跳号范围

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