Spring Boot+Hibernate环境下反馈点赞表是否需单独ID列？

我正在为反馈功能构建新表，后端基于Java、Spring Boot开发并使用Hibernate。现有建表语句采用user_id与comment_id作为复合主键，有以下疑问：

1. 是否需要添加单独ID列？
2. 这会影响查询速度吗？
3. 数据库模型绑定速度会更快吗？
4. 最优表构建方式是什么？

现有建表SQL：

CREATE TABLE feedback_helpful (
user_id BIGINT NOT NULL,
comment_id BIGINT NOT NULL,
timestamp TIMESTAMP DEFAULT NOW(),
FOREIGN KEY(user_id) REFERENCES users(id),
FOREIGN KEY(comment_id) REFERENCES feedback_comment_public(id),
PRIMARY KEY(user_id, comment_id)
);

是否需要添加单独ID列？ #

不需要。你的业务场景是记录用户对评论的点赞行为，user_id + comment_id本身就天然具备唯一性（一个用户不可能对同一条评论重复点赞），完全可以作为主键使用。单独ID列在这里属于冗余字段，除非后续有需要将这条点赞记录作为其他表关联主表的场景（比如新增点赞操作审计表），否则没必要额外添加。

对查询速度的影响？ #

用复合主键反而更利于查询性能：

• 以InnoDB为例，主键本身就是聚簇索引，查询时如果按user_id+comment_id（比如判断用户是否点过赞），可以直接走聚簇索引，速度极快。
• 如果改用单独ID作为主键，你必须额外给user_id和comment_id建立唯一索引来保证业务唯一性，这会增加数据库的索引维护成本，且查询时需要走二级索引，性能反而不如复合主键的直接查询。

数据库模型绑定速度会更快吗？ #

差异可以忽略不计。Hibernate处理复合主键需要使用@EmbeddedId或者@IdClass来定义主键类，代码上会多一点工作量，但ORM映射的速度（也就是你说的模型绑定速度）本身没有明显差异。单独ID的话实体类写法更简单，但这只是开发体验的区别，不是性能层面的核心问题。

最优表构建方式？ #

保持你现有的复合主键方案就是最优选择，理由如下：

• 直接利用业务天然的唯一性约束，无需额外的唯一索引，减少数据库开销
• 主键索引直接覆盖核心查询场景（用户点赞校验、评论点赞数统计等），性能最优
• 避免冗余字段，表结构更简洁贴合业务逻辑

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