SQL-主键

🔑 SQL-主键

在关系型数据库中，主键是数据唯一性的核心保障。

📌 主键是什么？

定义：
主键是关系表中能唯一标识每条记录的字段或字段组合，确保表中任意两条记录不重复。
核心作用：

• 唯一标识记录（如学生表中的id）；
• 作为数据关联的基础（外键依赖主键）。

举例：

# students表（主键为id）
id,class_id,name,gender,score
1,1,小明,M,90
2,1,小红,F,95

⚠️ 主键的核心要求

1. 不可修改性
   主键一旦插入，尽量避免修改，否则会影响数据定位与关联逻辑。
2. 非空性
   主键字段不允许为NULL，确保唯一性约束有效。

🎯 主键设计原则：远离业务逻辑

反例：

• 身份证号、手机号、邮箱等业务字段不可作为主键！
  → 原因：业务字段可能变更（如用户修改手机号），导致主键修改成本高。

正解：
选择无业务含义的字段作为主键，例如：

💡 主键类型对比与选择

类型	特点	适用场景
自增整数	- 数据库自动生成，简单高效 - INT 类型上限约 21 亿，BIGINT 支持 922 亿亿	大多数业务场景（推荐）
GUID/UUID	- 全局唯一字符串（如8f55d96b-8acc-4636-8cb8-76bf8abc2f57） - 跨库插入无需冲突检测	分布式系统、前端生成主键

注意：

• 自增主键需注意字段类型上限，优先使用BIGINT AUTO_INCREMENT；
• GUID 主键虽无冲突问题，但字符串类型占用存储空间更大，查询效率略低。

⚙️ 联合主键：不得已的选择

定义：
由多个字段组合而成的主键，需所有字段值均相同才视为重复记录。
举例：

# 证件表（联合主键：id_num + id_type）
id_num,id_type,other_columns...
1,A,...   # 允许
2,A,...   # 允许（id_num不同）
2,B,...   # 允许（id_type不同）

适用场景：

• 必须依赖多个业务字段唯一标识记录；
• 尽量避免使用，会增加表设计复杂度与查询成本。

🚀 最佳实践总结

1. 优先选择自增主键

   • 单表场景首选BIGINT AUTO_INCREMENT，兼顾性能与便捷性。

2. 分布式场景用 GUID

   • 多节点并发插入时，通过 UUID 算法（如 Java 的UUID.randomUUID()）保证唯一性。

3. 杜绝业务字段主键

   • 业务字段变更风险高，违反 “主键不可修改” 原则。

4. 联合主键作为备选

   • 仅在必要时使用，确保组合字段逻辑上绝对唯一。

🌟 总结

主键设计是数据库建模的基础，核心原则是：无业务含义、稳定唯一、性能优先。合理选择主键类型，能避免后续业务扩展中的数据隐患，为系统稳定性打下坚实基础。