数据库设计|唯一性约束 数据库候选码设置方法与技巧分享，如何正确设置数据库候选码

🔍 数据库设计 | 唯一性约束：候选码设置的艺术与技巧

场景引入：
想象你正在设计一个电商平台的数据库 📦，用户表里突然出现了两个"张三"，订单表里同一订单ID被重复使用...数据混乱得像打翻的颜料盘 🎨，这时候，候选码（Candidate Key）就是你的救星！它能确保数据的唯一性，就像给每件商品贴上独一无二的条形码一样靠谱 💯。

什么是候选码？

候选码是能唯一标识表中每行数据的最小属性集合，它有两个关键特点：

• 唯一性：就像身份证号，不允许重复 🆔
• 最小性：不能去掉任何一个属性（姓名+生日"组合唯一时，单用姓名就不行）

🔹 经典例子：

• 学生表：学号是候选码，身份证号也是候选码
• 订单表：订单ID是候选码，用户ID+下单时间戳也可能是候选码

候选码 vs 主键 vs 唯一约束

💡 小技巧：主键一定是候选码，但候选码不一定是主键，就像CEO一定是高管，但高管不一定是CEO 👔

候选码设置实战技巧

技巧1：自然属性优先

优先选择业务中天然唯一的属性：

-- 好的候选码（身份证号本身唯一）
CREATE TABLE users (
    id_card CHAR(18) UNIQUE,  -- 候选码1
    phone VARCHAR(11) UNIQUE   -- 候选码2
);

技巧2：组合键的智慧

当单列无法保证唯一时,试试属性组合：

-- 课程表：同一教室同一时间段只能有一门课
CREATE TABLE courses (
    course_id INT PRIMARY KEY,
    classroom VARCHAR(10),
    time_slot DATETIME,
    UNIQUE (classroom, time_slot)  -- 候选码
);

技巧3：警惕"唯一陷阱"

这些情况可能导致候选码失效：

• 允许NULL值（NULL不等于NULL，可能破坏唯一性）🚫
• 过长的字符串组合（影响性能）🐢
• 频繁更新的列（不适合作为候选码）🔄

候选码选择最佳实践

1. 稳定性原则：选不常变更的属性（如身份证号比手机号更稳定）
2. 简洁性原则：能用单列就不用多列组合
3. 业务匹配原则：符合业务查询习惯（比如按订单号查比按"用户ID+时间"更直观）

🎯 真实案例：
某图书馆系统最初用(书名+出版社)作为书籍候选码，后来发现同书名同出版社不同版次的书会冲突，最终改为ISBN作为主键。

常见问题QA

❓ Q：一个表可以有多个候选码吗？
✅ 当然可以！比如员工表同时有员工ID和社保号两个候选码

❓ Q：所有表都需要候选码吗？
✅ 理论上需要，但有些中间表（如订单-商品关联表）可能用联合主键即可

❓ Q：候选码和索引有什么关系？
🔍 数据库通常会自动为候选码创建唯一索引，但你可以额外添加普通索引加速查询

Checklist

设置候选码时,记得问自己：

1. 这个组合能100%确保唯一吗？🔐
2. 是否有更简单的方案？✂️
3. 是否符合业务查询模式？🛒
4. 未来数据增长会影响唯一性吗？📈

掌握候选码设计,你的数据库就能像瑞士手表一样精准运转⏱️！如果有疑问，欢迎在评论区讨论~ 👇

（本文参考数据库设计规范及2025年行业实践整理）