唯一约束和主键索引有何区别？

Question

在数据库设计中，唯一约束（Unique Constraint）和主键索引（Primary Key）都用于保证数据的唯一性，但它们有何本质区别？常见问题如下： **问题：** 一个表中可以有多个唯一约束，但只能有一个主键。主键不仅要求字段值唯一，还必须非空（NOT NULL），而唯一约束允许一个NULL值（具体行为因数据库而异）。此外，主键会自动创建聚集索引（在多数数据库中如SQL Server），而唯一约束通常创建非聚集唯一索引。那么，在实际应用中，若将业务主键设为唯一约束而非主键，是否会影响性能和外键引用？两者在索引机制、存储结构和外键关联上的差异究竟如何影响系统设计？

Answer 1

1. 基本概念对比：主键与唯一约束的本质区别

在关系型数据库设计中，主键（Primary Key）和唯一约束（Unique Constraint）均用于确保字段或字段组合的值在表中唯一。但二者在语义、行为和实现机制上存在本质差异。

• 主键：必须唯一且非空（NOT NULL），一个表只能有一个主键。
• 唯一约束：允许唯一性，但多数数据库系统（如MySQL、PostgreSQL）允许一个NULL值存在（多个NULL可能被视为不重复）。
• 主键自动创建索引，通常为聚集索引（Clustered Index），而唯一约束创建的是非聚集唯一索引（Non-Clustered Unique Index）。
• 主键可被外键引用，是参照完整性的基础；唯一约束也可作为外键目标，但需显式指定且受数据库支持限制。

2. 索引机制与存储结构分析

主键与唯一约束在底层索引结构上的差异直接影响数据存储和查询性能。

特性	主键	唯一约束
是否自动创建索引	是	是
默认索引类型（SQL Server）	聚集索引	非聚集索引
存储组织方式	数据行按主键物理排序	索引独立于数据存储
插入性能影响	高（需维护物理顺序）	较低（仅维护B+树）
范围查询效率	极高（连续I/O）	依赖非聚集索引覆盖

3. 外键关联能力与参照完整性

外键（Foreign Key）可以引用主键或唯一约束列，但实际使用中存在显著差异。

-- 示例：外键引用唯一约束而非主键 CREATE TABLE users ( id BIGINT PRIMARY KEY, email VARCHAR(255) UNIQUE NOT NULL ); CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, user_email VARCHAR(255), FOREIGN KEY (user_email) REFERENCES users(email) );

上述代码合法，但存在风险：若唯一约束列允许NULL，则外键引用将受限（外键列也需处理NULL语义）。此外，某些ORM框架对非主键引用支持不完善，可能导致映射异常。

4. 性能影响深度剖析

将业务主键设为唯一约束而非主键，会引发一系列性能与架构问题：

1. 失去聚集索引优势：若未另行指定聚集索引，数据将以堆（Heap）形式存储，导致全表扫描成本升高。
2. JOIN操作效率下降：外键连接基于非聚集索引查找，需额外书签查找（Bookmark Lookup）获取数据行。
3. 分页查询性能劣化：ORDER BY 主键 的高效跳过策略失效。
4. 碎片化加剧：频繁更新唯一约束列会导致非聚集索引碎片增加。
5. 统计信息准确性降低：优化器对非主键唯一索引的选择率估算可能偏差较大。

5. 实际应用场景与设计权衡

尽管技术上可行，但在大多数系统中将业务主键设为唯一约束而非主键属于反模式。以下是典型场景对比：

graph TD A[选择主键还是唯一约束?] --> B{是否天然唯一且稳定?} B -->|是| C[推荐设为主键] B -->|否| D[设为唯一约束, 使用代理主键] C --> E[获得聚集索引+外键友好] D --> F[避免业务变更导致主键修改]

6. 数据库厂商行为差异

不同RDBMS对NULL值在唯一约束中的处理存在分歧：

• MySQL：InnoDB中唯一约束允许多个NULL（视为不相等）。
• PostgreSQL：唯一约束允许多个NULL。
• SQL Server：唯一约束仅允许一个NULL值（ANSI标准兼容）。
• Oracle：唯一索引中多个NULL不违反约束（因NULL != NULL）。

这种差异直接影响跨平台迁移时的数据一致性保障策略。