主键约束的要求——主键约束需唯一
深入解析数据库主键设计的核心原则：唯一性、非空性与稳定性。从原理到实战，全面拆解主键约束如何影响数据一致性、查询性能与系统扩展性。
主键约束的本质要求
在关系型数据库（RDBMS）中，主键约束（Primary Key Constraint）是表结构设计中最基础、最关键的完整性约束之一。其核心要求可概括为：主键约束需唯一，且不允许为空值（NOT NULL）。
主键的三大铁律
- 唯一性：同一表中，任意两行的主键值不得相同
- 非空性：主键字段不能为 NULL；若为复合主键，任一字段为 NULL 即导致整行被拒绝插入
- 稳定性：主键值应尽量避免更新，因其可能被外键引用，变更将引发连锁影响
注意：主键不等于“自增ID”。虽然自增整型（如 INT AUTO_INCREMENT）是常见主键实现方式，但主键本质上是逻辑概念，可以是业务字段（如身份证号、订单编号），前提是满足唯一性与非空性。
主键 ≠ 唯一键（UNIQUE KEY）
虽然唯一键（UNIQUE KEY）也要求值不重复，但与主键存在关键差异：
- 主键列不允许 NULL；唯一键列允许最多一个 NULL（部分数据库如 MySQL 允许多个 NULL，但 PostgreSQL 仅允许一个）
- 张表只能有一个主键；但可以有多个唯一键
- 主键自动创建聚簇索引（如 InnoDB）；唯一键默认为非聚簇索引
为何“主键约束需唯一”？——从现实场景说起
让我们回到一个经典案例：张三、李四、王五……名字看似普通，但若将其设为员工表的主键，系统将面临严峻挑战。
插入三条记录（张三、李四、王五）。若张三名字被误输为“张山”，系统无法识别——因主键必须唯一，此时无法再插入“张三”，除非先删除“张山”，再修正后重插。
备份后系统重启。若恢复时出现同名冲突（如原“张三”与备份数据中的“张三”重复），数据库会拒绝恢复，导致备份失效。
张三改名为“张伟”。若主键为“姓名”，则需更新整表所有关联记录（工资单、工单、日志等），操作复杂度呈指数级上升。
唯一性保障的三大核心价值
唯一标识每一行记录
数据库表本质是无序集合。若无唯一主键，系统无法精准定位某条记录。例如：
确保数据一致性与可追溯性
主键是外键引用的基础。若主键不唯一，外键将无法可靠指向目标记录，导致数据断裂。
案例：工资表中“张三”发薪 3000，员工表中“张三”信息仍为 3005——系统无法自动校验冲突，必须依赖人工干预。而若使用主键 ID（如 emp_id=1002），则可强制外键约束，确保一致性。
提升索引与查询效率
主键自动创建唯一索引。无主键时，数据库需全表扫描定位数据，尤其在大数据量下性能急剧下降。
例如：图书馆无 ISBN 编号，仅靠书名找书——若多本同名书，需逐本翻查；而有 ISBN 后，系统可直接定位到具体副本。
主键设计实践：从策略到案例
主键选择是一门“艺术”，需综合考虑业务语义、性能、扩展性与维护成本。以下为常见策略对比：
主键类型对比表
| 类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 自增整型（INT/AUTO） | 存储小、索引高效、插入快 | 跨库迁移易冲突；业务无语义 | 事务型业务表（如订单、用户） |
| UUID（随机字符串） | 全局唯一；支持分布式 | 索引碎片多；存储空间大（36字符） | 微服务、多实例部署系统 |
| 业务字段（如身份证号） | 语义清晰；无需额外字段 | 字段变更成本高；长度不固定 | 强唯一业务字段（如税号、学籍号） |
| 组合主键（如日期+编号） | 业务可读；避免自增冲突 | 外键引用复杂；更新风险高 | 日志表、时间序列数据 |
推荐实践：代理主键（Surrogate Key）优先
现代数据库设计普遍采用“代理主键”——即人为构造的、与业务无关的字段作为主键（如自增ID）。原因如下：
- 业务字段可能变化（如姓名、电话），而主键应保持稳定
- 避免因业务规则变更导致主键重构
- 简化外键引用（仅需单字段）
复合主键的合理使用场景
当业务天然具有组合唯一性时，可考虑复合主键。例如：
此处，同一学生同门课程同一天只能选一次——复合主键天然满足此约束，无需额外唯一索引。
主键缺失对性能的毁灭性影响
没有主键的表被称为“堆表”（Heap Table）。在 InnoDB 引擎中，若未定义主键，系统会隐式创建一个 6 字节的 ROWID 作为内部主键——但这并非业务可见，且无法利用其优化查询。
性能对比实测（100万行数据）
主键表：使用主键索引，时间 0.002s
堆表：全表扫描，时间 1.85s
主键表：利用聚簇索引，直接定位起始点，时间 0.008s
堆表：扫描整个表，时间 2.31s
主键表：优化器可精准使用索引，执行计划高效
堆表：需额外创建索引，否则 JOIN 变成嵌套循环全扫描
主键与聚簇索引（Clustered Index）
在 InnoDB 中，主键即聚簇索引——数据按主键顺序物理存储。这意味着：
- 主键越短，索引越高效（整表数据随主键增长而膨胀）
- 主键更新会导致行迁移（Row Migration），引发页分裂
- 级索引存储的是主键值——主键大则所有二级索引也大
因此，主键约束需唯一的同时，也应追求短小、稳定、递增。
主键设计常见误区与避坑指南
误区1：“主键必须是数字”
错误。主键可以是任意数据类型（CHAR、VARCHAR、UUID等），只要满足唯一性即可。例如：使用 UUID 作为主键在分布式系统中非常普遍。
误区2：“自增主键永远安全”
自增主键在分库分表时易冲突。例如：两个实例同时生成 ID=10001，合并数据时主键冲突。解决方案：使用雪花算法（Snowflake）或数据库序列（Sequence）生成全局唯一ID。
误区3：“主键不能更新”
技术上允许更新主键（如 InnoDB 支持），但强烈不推荐！因外键引用、缓存失效、触发器连锁反应，可能导致数据不一致。正确做法：通过业务层避免主键变更，或使用代理主键隔离业务字段。
误区4：“唯一键可替代主键”
唯一键满足唯一性，但允许 NULL，无法作为外键引用的可靠目标。且一张表可有多个唯一键，系统无法确定哪个应作为主键。因此，业务唯一字段应加 UNIQUE 约束，而主键仍需独立定义。
何时不该用主键？
以下场景可考虑不设主键（但需谨慎）：
- 临时日志表（仅追加写入，无需更新/删除）
- 审计日志（历史数据只读，且可通过时间戳+序号定位）
- 数据仓库宽表（ETL后仅用于分析，不参与实时事务）
注意：即使在上述场景，也强烈建议添加自增ID作为逻辑主键，便于后续维护与调试。
网友们还关心的问题
主键不限制类型。字符串主键（如 UUID、业务编码）在以下情况可能影响性能：
- 索引体积更大：UUID 占用36字节 vs INT 的4字节
- 页分裂更频繁：随机UUID导致B+树频繁重组
- JOIN 时比较开销高
但现代SSD+内存充足时，差异通常在毫秒级。若业务强需求（如全球唯一订单号），优先保障业务逻辑，性能可通过分页缓存、读写分离优化。
不可以！一张表只能有一个主键，但该主键可以是多个字段的组合（称为“复合主键”或“联合主键”）。例如：
此时，(order_id, product_id) 的组合必须唯一，但单独字段可重复。
插入重复主键时，数据库会返回错误，例如：
此时需检查业务逻辑：是否重复提交？是否未使用事务？或考虑用 INSERT IGNORE / ON DUPLICATE KEY UPDATE 处理。
操作步骤如下（以 MySQL 为例）：
注意：操作前务必备份！若存在外键引用，需先删除外键约束。
结语：主键是数据世界的“身份证号”
“主键约束需唯一”不仅是技术规则，更是数据治理的基石。一个设计良好的主键，能让系统在数据一致性、查询性能、扩展性上获得长期收益；而一个草率选择的主键，可能在业务增长时成为致命瓶颈。
请始终牢记：
- 主键是逻辑唯一标识符，而非业务字段的简单映射
- 优先选择短小、稳定、递增的代理主键
- 业务唯一字段应加 UNIQUE 约束，而非强塞为主键
- 主键设计需前瞻性——它影响的不仅是现在，更是未来三年的系统演进
当您下次设计表结构时，请多问一句：这个主键，十年后还能稳如磐石吗？