Timescale Hypertable是否建议设置主键？远程设备时序数据场景咨询

优势 #

• 适配传统开发习惯：如果团队成员熟悉传统关系型数据库，自增ID主键能降低学习成本，不用纠结无主键表的操作逻辑，ORM映射、单条数据定位这类日常操作更顺畅。
• 绝对唯一标识：虽然device_id + timestamp是主要过滤条件，但同一设备同一时间可能产生多条相同value的数据，自增ID能确保每条数据有独一无二的标识，方便后续排查重复、修改或删除单条记录。
• 兼容第三方工具：部分ORM框架、数据同步工具默认要求表有主键，自增ID可以避免这类工具适配时的兼容性问题。

劣势 #

• 写入性能损耗：每次插入都要调用PostgreSQL的sequence生成ID，高并发写入场景下（尤其是时序数据常见的批量插入），额外的ID生成和主键索引维护会带来额外开销。而且Hypertable按时间分片，自增ID主键的索引会跨分片分布，进一步影响写入和查询效率。
• 资源冗余浪费：你的核心查询依赖device_id + timestamp，自增ID在这类查询中完全没用，但其主键索引会占用额外存储空间，数据库查询时也不会用到这个索引，属于无效资源消耗。
• 违背时序优化逻辑：Timescale对Hypertable的优化都是围绕时间分片、时间+设备的复合维度展开的。自增ID主键会打破这种优化逻辑，甚至可能让查询规划器做出非最优的执行计划。

更优的替代方案 #

既然device_id + timestamp无法保证唯一性，你可以：

• 创建复合唯一约束：(device_id, timestamp, value)，用这三个字段的组合确保记录唯一；
• 如果允许value重复，可添加一个轻量级的区分字段（比如设备端生成的序号，或插入时的本地自增数），将(device_id, timestamp, sequence_num)设为复合主键，这样既保证唯一性，又能和Timescale的分片优化对齐，避免自增ID带来的弊端。

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