SQL主键约束和唯一约束有什么区别

在关系型数据库设计中，PRIMARY KEY（主键）和 UNIQUE（唯一约束）都能保证列值的唯一性，但它们的职责边界截然不同。主键的核心任务是唯一标识每一行数据，因此隐含了非空（NOT NULL）要求，且一张表通常只能有一个；而唯一约束主要用于限制业务字段的重复，允许存在多个，且对 NULL 值的处理因数据库而异。理解这两者的差异，是构建健壮表结构的基础。

先看目标：标识行还是限制重复

在设计 users 表时，我们通常会遇到两个需要唯一的字段：id 和 email。虽然它们都不能重复，但背后的逻辑完全不同。

id 作为主键，是数据库内部识别这条记录的“身份证号”。它必须稳定、非空，并且常被其他表（如 orders 订单表）通过外键引用。如果 id 为空或重复，数据库将无法准确定位记录，参照完整性也会崩溃。

email 作为业务字段，其唯一性是为了防止用户重复注册。它适合使用 UNIQUE 约束。即使邮箱地址未来可能变更，或者在某些极端业务场景下允许为空（取决于具体需求），它也不应轻易替代 id 成为主键，因为业务字段往往缺乏主键所需的绝对稳定性。

PRIMARY KEY 标识行，UNIQUE 限制业务字段重复

上图展示了 users 表中 id 与 email 的角色对照：id 被标记为 PRIMARY KEY，承担行标识和外键引用的核心职责；email 被标记为 UNIQUE，仅负责业务层面的去重。当尝试插入重复邮箱时，数据库会直接拒绝，从而保护业务逻辑的正确性。

PRIMARY KEY 的规则与复合键

主键约束不仅要求值唯一，还强制要求值不为 NULL。在 SQL 标准中，一张表只能定义一个 PRIMARY KEY 约束。这个约束可以是单列，也可以是多列组成的复合主键。

单列主键

这是最常见的形式，通常使用自增整数或 UUID。

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100)
);

复合主键

在某些关联表或历史数据表中，可能需要多个字段共同确定唯一性。例如，记录学生在某门课程的考试成绩，可以用 student_id 和 course_id 组合作为主键。

CREATE TABLE student_scores (
    student_id INT,
    course_id INT,
    score DECIMAL(5, 2),
    PRIMARY KEY (student_id, course_id)
);

复合主键意味着 student_id 和 course_id 的组合必须唯一，但单独的 student_id 可以重复（因为一个学生可以选多门课）。需要注意的是，虽然复合主键在逻辑上成立，但在现代开发中，为了简化外键引用和 ORM 映射，许多团队倾向于使用单列代理主键（如 id），而将原来的复合逻辑降级为 UNIQUE 约束。

UNIQUE 的多个约束与 NULL 细节

与主键不同，一张表可以定义多个 UNIQUE 约束。这非常适合用于保护多个业务字段的唯一性，如邮箱、手机号或用户名。

单列与组合唯一约束

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE,
    phone VARCHAR(20) UNIQUE,
    CONSTRAINT uk_user_region UNIQUE (username, region_code)
);

这里定义了三个唯一约束：email 单独唯一，phone 单独唯一，以及 username 和 region_code 的组合唯一。这意味着同一个用户名可以在不同地区存在，但在同一地区内必须唯一。

NULL 行为的跨库差异

UNIQUE 约束最容易被忽视的细节是对 NULL 值的处理。SQL 标准认为 NULL 不等于任何值，包括另一个 NULL。但在实际数据库中，实现方式存在差异：

• PostgreSQL：遵循 SQL 标准，允许在 UNIQUE 列中存在多个 NULL 值。因为 NULL != NULL，所以不违反唯一性。
• MySQL：在 InnoDB 引擎中，UNIQUE 索引也允许多个 NULL 值。
• SQL Server：默认情况下，UNIQUE 约束只允许一个 NULL 值。如果需要多个 NULL，需要使用过滤索引（Filtered Index）。
• SQLite：允许在 UNIQUE 列中有多个 NULL。

单列、复合 UNIQUE 及 NULL 规则的对照

上图对比了单列唯一、复合唯一以及 NULL 在不同场景下的行为。特别注意复合唯一约束中，如果其中一列为 NULL，不同数据库对“重复”的判断逻辑可能更为复杂。因此在设计允许为空的唯一字段时，务必查阅所用数据库的具体文档。

按稳定性与业务语义做选择

在实际开发中，选择主键还是唯一约束，应遵循以下原则：

1. 稳定性优先：主键一旦被外键引用，修改成本极高。因此，主键应选择永不改变或极少改变的字段（如自增 ID、UUID）。业务字段（如邮箱、手机号）可能随用户行为变更，不适合做主键。
2. 语义分离：用 PRIMARY KEY 解决“这是哪一行”的问题，用 UNIQUE 解决“这个业务值是否重复”的问题。不要试图用一个字段承担所有责任。
3. 依赖数据库约束：不要在应用层只做唯一性校验。并发请求可能导致“检查时存在，插入时重复”的竞争条件。必须在数据库层面添加 UNIQUE 约束，并捕获相应的错误代码（如 PostgreSQL 的 23505）进行友好提示。

验证设计

可以通过查询系统 catalog 或尝试插入冲突数据来验证约束是否生效。例如，在 PostgreSQL 中：

-- 查看表的约束信息
SELECT conname, contype 
FROM pg_constraint 
WHERE conrelid = 'users'::regclass;

如果插入重复邮箱导致报错，且错误信息指向 users_email_key 约束，则说明设计已正确落地。

参考资料

• PostgreSQL primary keys and unique constraints
• MySQL PRIMARY KEY and UNIQUE
• SQL Server primary and unique constraints
• SQLite CREATE TABLE constraints