MySQL表主键设计最佳实践：解决Event_places表的NULL主键冲突问题

核心思路 #

保留原有的event_id、dog_id、score_type_id作为主键（保证必填字段的基础唯一性），针对两种互斥场景分别添加部分唯一约束，精准控制不同字段组合下的记录唯一性，无需拆分表或伪造无效数据。

具体实现（以支持部分索引的数据库为例，如PostgreSQL、SQL Server） #

1. 维持原主键定义：

   PRIMARY KEY (event_id, dog_id, score_type_id)
   

2. 为「存在round但无waitlist_type_id」的场景添加唯一约束：

   CREATE UNIQUE INDEX idx_event_places_round_unique 
   ON Event_places (event_id, dog_id, score_type_id, round)
   WHERE waitlist_type_id IS NULL;
   

3. 为「存在waitlist_type_id但无round」的场景添加唯一约束：

   CREATE UNIQUE INDEX idx_event_places_waitlist_unique 
   ON Event_places (event_id, dog_id, score_type_id, waitlist_type_id)
   WHERE round IS NULL;
   

方案优势 #

• 避免表拆分冗余：不用为N种场景创建大量表，保持数据结构的一致性，降低维护成本。
• 符合外键规范：无需为waitlist_type_id或round创建无效的外键条目（比如-1），严格遵循数据库约束规则。
• 精准控制唯一性：从数据库层面直接杜绝业务逻辑上的重复记录，比单独生成唯一ID更可靠（唯一ID无法防止同业务属性的重复录入）。

兼容旧版数据库的替代方案（如MySQL 5.7及以前） #

如果数据库不支持部分唯一约束，可通过COALESCE处理空值，创建组合唯一索引：

CREATE UNIQUE INDEX idx_event_places_combined_unique 
ON Event_places (
  event_id, 
  dog_id, 
  score_type_id, 
  COALESCE(waitlist_type_id, -1), 
  COALESCE(round, -1)
);

注意：需确保-1不会出现在waitlist_type_id或round的正常业务值中，避免冲突。

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