主键是数据库中确保数据唯一性和非空性的核心机制，其核心作用体现在三方面：第一，强制唯一性，任何两行数据的主键值不能相同；第二，强制非空性，主键列的值不能为null；第三，作为性能优化和表间关系建立的基础。主键被称为数据库的“身份证”，因其能唯一标识每条记录，防止重复数据，保障数据完整性。在设计主键时，需权衡业务主键与代理主键（如自增id或uuid），自增id适用于单体应用、数据量可控的场景，具备高效、易读等优点，而uuid适合分布式系统，具有全局唯一性但索引性能较差。最终选择应根据项目规模、架构、性能要求及扩展性综合判断。
数据库主键约束，简单来说，就是给表里的每一行数据一个独一无二的“身份证号”。它确保了每条记录都能被唯一标识，而且这个标识符绝对不能为空，是数据库中保障数据完整性和高效查询的核心机制。
解决方案
主键约束是关系型数据库设计中不可或缺的一环。它不仅仅是一个简单的索引，更是一种数据完整性规则的体现。一个表只能有一个主键，但这个主键可以由一个或多个列组成（复合主键）。它的核心作用在于：第一，强制唯一性，任何两行数据的主键值都不能相同；第二，强制非空性，主键列的值不能为NULL。这两点共同构成了数据识别的基础，使得我们能够准确无误地定位、更新或删除特定记录，也为表与表之间建立关联（通过外键）提供了坚实的基础。
为什么说主键是数据库的“身份证”？它的核心作用体现在哪里？
把主键比作数据库的“身份证”，这说法其实挺贴切的。你想想，身份证最重要的功能是什么？唯一标识一个人，不能有重复，也不能没有。数据库主键也是如此，它赋予了每一条记录独一无二的身份。
这种“身份证”般的核心作用，首先体现在数据唯一性上。如果没有主键，理论上你可以在一张表里插入多条完全相同的数据，比如两个“张三，男，25岁”。这在业务上是灾难性的，当你需要查找或更新“张三”的信息时，系统会无所适从。主键的存在，从根本上杜绝了这种重复，确保了数据的纯净度。
其次是数据非空性。一个没有身份证号的人，在很多场景下是无法被识别和管理的。同样，如果主键允许为空，那这条记录就失去了唯一的标识，变得“无名无姓”，这显然与主键的初衷相悖。所以，主键列的值必须始终存在。
再来，主键是性能优化的利器。几乎所有数据库系统都会为主键自动创建索引，而且通常是聚簇索引（如果数据库支持的话）。这意味着数据在物理存储上会按照主键的顺序排列，这对于基于主键的查询（WHERE id = 123）和连接操作（JOIN ON table1.id = table2.fk_id）来说，效率是极高的，因为它减少了磁盘I/O和数据查找的时间。我个人经历过很多次，当一个查询慢如蜗牛时，往往发现其连接的表缺乏合理的主键或索引，一旦加上，性能立马“飞”起来。
最后，也是关系型数据库的精髓所在，主键是建立表间关系的基础。通过主键和外键的关联，我们能够将分散在不同表中的相关数据连接起来，形成一个完整的业务视图。比如，订单表通过customer_id（外键）关联客户表的主键，从而知道是哪个客户下了订单。没有主键，关系型数据库的“关系”就无从谈起，整个数据模型会像一盘散沙。
如何科学设计数据库主键？自增ID还是UUID，我该如何选择？
主键的设计，这确实是个值得深思的问题，没有一劳永二的“最佳实践”，更多的是权衡取舍。核心在于，你是选择一个有业务意义的“业务主键”，还是一个纯粹为了标识而生的“代理主键”。
业务主键，比如一个商品的SKU码，或者一个用户的手机号（如果确保唯一且不变）。它的优点是直观、有意义，查询时可以直接使用业务值。但缺点也很明显：业务规则可能变化，导致主键值需要更新（这是大忌，主键最好是永不变化的）；它可能很长，占用存储空间；有时还涉及隐私问题。
而我们通常讨论的代理主键，就是那些与业务逻辑无关，纯粹为了唯一标识而生成的值。这里主要就是自增ID和UUID的较量。
自增ID（如MySQL的AUTO_INCREMENT，PostgreSQL的SERIAL）
UUID（Universally Unique Identifier）
我的选择倾向：
对于单体应用、数据量可控、不需要跨库合并数据的场景，我几乎总是推荐使用自增ID。它简单、高效、易于管理，能满足绝大多数业务需求。性能上的优势是实实在在的。
但如果你的项目是微服务架构、需要数据分片、跨地域部署、或者有离线数据生成并最终合并的需求，那么UUID的全局唯一性优势就变得不可替代。当然，UUID的索引性能问题可以通过一些优化手段来缓解，比如使用有序的UUID（如ULID或UUIDv7），它们在生成时就考虑了时间戳，使其具有一定的顺序性，从而改善索引性能。或者，可以考虑将UUID作为业务主键，而内部存储和查询仍然使用一个自增的代理主键，通过索引来关联。这是一种折衷但有效的方案。
最终，选择哪种主键，就像选择一把趁手的工具，需要根据你的项目规模、架构、性能要求和未来扩展性来综合判断。
实际操作：如何在主流数据库中设置主键约束？
设置主键约束，在SQL中是相当直观的。无论是创建新表时定义，还是对已有表添加，语法都比较统一。这里我以几个主流数据库为例。
1. 创建表时定义主键
这是最常见也最推荐的方式，因为它在表创建之初就确立了数据的完整性规则。
MySQL / PostgreSQL
-- MySQL 示例
CREATE TABLE users (
user_id INT AUTO_INCREMENT PRIMARY KEY, -- user_id 作为自增主键
username VARCHAR(50) NOT NULL UNIQUE,
email VARCHAR(100)
);
-- PostgreSQL 示例
CREATE TABLE products (
product_id SERIAL PRIMARY KEY, -- product_id 作为自增主键
product_name VARCHAR(100) NOT NULL,
price DECIMAL(10, 2)
);
-- 使用UUID作为主键 (MySQL)
CREATE TABLE orders (
order_id CHAR(36) PRIMARY KEY, -- UUID通常存储为CHAR(36)或BINARY(16)
customer_id INT NOT NULL,
order_date DATETIME
);
-- 插入时需要手动生成UUID，例如在应用层生成或使用数据库函数UUID()
-- INSERT INTO orders (order_id, customer_id, order_date) VALUES (UUID(), 101, NOW());
-- 使用UUID作为主键 (PostgreSQL)
-- 需要启用uuid-ossp扩展
-- CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE TABLE sessions (
session_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY, -- 使用函数自动生成UUID
user_id INT,
start_time TIMESTAMP WITH TIME ZONE
);2. 为已有表添加主键约束
如果你有一张老表，或者创建时忘记了定义主键，也可以后续添加。但要注意，添加主键前，确保目标列的数据满足唯一性和非空性，否则会报错。
MySQL / PostgreSQL
-- 假设有一个表 employees，其中 employee_id 列是唯一的且非空 ALTER TABLE employees ADD PRIMARY KEY (employee_id); -- 如果是复合主键（由多个列组成的主键） -- 假设 orders_items 表中，order_id 和 item_id 组合是唯一的 ALTER TABLE order_items ADD PRIMARY KEY (order_id, item_id);
一些需要注意的细节：
ALTER TABLE table_name DROP PRIMARY KEY;。但如果存在外键引用，你需要先删除或修改那些外键约束。在实际项目中，我见过很多因为主键设计不当导致的问题，比如ID冲突、查询性能瓶颈、数据难以合并等等。所以，在数据库设计阶段，花时间思考并确定合适的主键策略，绝对是值得的投资。
以上就是数据库主键约束是什么？主键的设计、作用及设置指南的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
366
收藏
