移除自增主键id改用联合唯一键作为主键是否可行？性能影响如何？

一、改用(audio_id,hour_int)作为主键是否合理？ #

这种做法是完全合理的，甚至更贴合你的业务场景，原因如下：

• 符合主键核心约束：audio_id和hour_int的联合唯一键本身满足「非空+唯一」的主键要求，完全可以替代原自增主键。
• 彻底解决主键溢出问题：原int主键溢出后改bigint只是临时方案，bigint虽上限极高，但长期高频率写入（哪怕大部分被删除）仍存在理论溢出风险；改用业务字段联合主键后，彻底摆脱自增主键的溢出隐患。
• 节省存储开销：去掉id列后，每条记录减少8字节（bigint类型长度），同时原有的(audio_id,hour_int)二级唯一索引会被主键索引替代，省去了二级索引的存储成本，对于千万级规模的表，能显著降低存储空间占用。

二、对插入、查询等操作的性能影响 #

1. 插入性能 #

• 正向优化点：原架构下插入时需要同时维护主键聚簇索引和(audio_id,hour_int)二级唯一索引；改用联合主键后，只需维护聚簇索引，少了一层索引维护开销，这部分能提升插入效率。
• 潜在风险：InnoDB的聚簇索引依赖主键顺序，原自增主键是严格顺序写入，不会触发索引页分裂；如果你的写入是乱序的（比如不同audio_id穿插写入、hour_int非递增），联合主键的插入会导致频繁的聚簇索引页分裂，降低插入性能。但如果你的写入是按hour_int批量处理同audio_id的数据，或者整体写入顺序相对有序，页分裂的影响会很小。

2. 查询性能 #

• 核心查询大幅优化：如果你的业务查询大多是基于audio_id+hour_int的（比如查询某音频某小时的排名数据），改用联合主键后，这类查询直接走聚簇索引，无需回表（原架构下要先查二级索引再回表查主键数据），性能会明显提升。
• 需规避的坑：如果原有代码存在依赖id列的查询/更新/删除操作，必须全部改为用audio_id+hour_int作为条件；若未修改，这类操作会变成全表扫描，性能暴跌。但从业务逻辑看，这类依赖自增id的操作本就不符合业务语义，调整后反而更合理。

3. 其他性能相关影响 #

• 删除性能优化：由于你的业务中99.99%的记录会被删除，若删除是按hour_int范围执行（比如删除N天前的数据），hour_int作为联合主键的后缀，能高效定位到需要删除的索引范围，删除效率比原自增主键更高。
• 碎片问题：若插入乱序，聚簇索引的碎片会比自增主键多，但结合你高删除率的场景，定期执行OPTIMIZE TABLE或利用分区表按hour_int分区（进一步优化批量删除），可以有效缓解碎片问题。

三、总结 #

改用(audio_id,hour_int)作为主键是适配你业务场景的合理方案，只要调整代码消除对原id列的依赖，并尽量保证写入顺序相对有序，整体性能会优于原架构，还能彻底解决主键溢出的隐患。

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