Postgres/TimescaleDB复合唯一键对插入性能的影响如何？

实际性能影响 #

首先明确你当前每分钟数百次写入的场景下，建合规的复合唯一键几乎不会带来可感知的性能影响，不用过度焦虑：

• 复合唯一键的底层是B树结构，每次写入的额外开销只有一次B树查找校验重复的成本，以及索引本身的存储成本。如果from/to/code/point是常规整型、定长短字符类型，单条索引条目体积极小，存储膨胀率通常在20%~30%区间，常规服务器配置下，单实例承载每秒数千次写入都不会因为这个索引出现瓶颈。
• 这里有个TimescaleDB专属的注意点：所有唯一约束必须包含hypertable的时间分区键，如果你只给from/to/code/point四个字段建唯一键、不带时间字段，约束会直接创建失败，这是时序分区机制带来的原生限制，不要硬绕。
• 如果强行建跨分区的全局唯一索引（通过禁用分区校验实现），写入时会扫描所有相关分区做重复判断，写入TPS会直接下降40%以上，且分区越多性能衰减越明显，非极端场景不推荐。

可选方案对比 #

你现在处于项目初期可以调整结构，三个主流方案的适配场景如下：

• 直接建带时间分区键的复合唯一约束
  把你设置的分区时间粒度（比如按小时分桶的时间字段、按天分桶的时间字段）和四个业务字段一起组成复合唯一键，是性价比最高的方案。写入开销最低，数据一致性由数据库原生保证，不需要额外写业务校验逻辑，完全覆盖你当前的写入规模，后续哪怕业务增长到每分钟数万次写入，只要硬件配置达标也不会出现性能问题。唯一的要求是业务上允许「相同四字段组合在不同时间分区下重复」，这也是绝大多数时序场景的实际逻辑。
• 业务层前置去重+普通复合索引
  如果你确实需要保证四个字段跨所有时间分区全局唯一，没法把时间字段放进唯一键，可以在写入前加一层轻量缓存（比如缓存最近1~2个小时的写入四字段组合）做前置去重，同时给四个字段建普通复合索引满足查询需求，后台定期跑低优先级任务清理极少量漏判的重复数据。这个方案写入性能比全局唯一键高很多，适合后续写入量级涨到每秒十万级以上、对性能极致敏感的场景，代价是要接受极低概率的重复数据风险。
• 应用层写入幂等保证
  如果后续单表写入量涨到百万级TPS，可以把去重逻辑完全下沉到写入前的消息队列/计算层，数据库只存最终去重后的数据，表上不建唯一键只建查询需要的普通索引，这是超大规模时序场景的通用方案，但初期用会带来不必要的开发复杂度。

落地建议 #

当前阶段直接选第一个方案，优先靠数据库原生约束保证数据一致性，不要为了不确定的未来性能做过度优化。等后续业务真的增长到现有方案扛不住的量级，再逐步切换到业务层去重的方案即可，改造成本很低。

数据库层的唯一约束是可靠性最高的去重手段，业务层手写的去重逻辑永远存在边界case漏判的可能，没有明确性能瓶颈前不要轻易放弃这个可靠性优势。

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