主键是数据库中确保数据唯一性和非空性的核心机制，其核心作用体现在三方面：第一，强制唯一性，任何两行数据的主键值不能相同；第二，强制非空性，主键列的值不能为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）
优点：简单易用： 数据库自动管理，你几乎不用操心。存储空间小： 通常是整数类型，占用4或8字节，非常高效。索引性能好： 因为是连续增长的，插入时对B+树索引的页分裂影响小，查询时局部性好，缓存命中率高。这对于高并发写入的场景尤其有利。可读性强： 1, 2, 3… 看着就舒服，方便调试和口头交流。缺点：不具备全局唯一性： 在分布式系统或多数据库合并的场景下，可能会出现ID冲突。安全性考虑： 容易被猜测，比如通过ID递增来爬取数据。分库分表难题： 在分库分表后，要保证全局唯一性需要额外的ID生成策略（如雪花算法）。
UUID（Universally Unique Identifier）
阿里云-虚拟数字人
阿里云-虚拟数字人是什么？ …
2 查看详情 
优点：全局唯一性： 理论上，UUID在任何时间、任何地点生成的ID都是独一无二的，非常适合分布式系统、微服务架构、数据同步或离线数据生成。安全性： 由于其随机性，很难被猜测或枚举。缺点：存储空间大： 通常是16字节（128位），比整数ID大得多，这意味着索引也更大，缓存能容纳的索引条目更少。索引性能差： UUID通常是无序的（尤其是版本4），插入时会导致B+树索引的随机写入，频繁的页分裂和碎片化，从而降低写入性能和查询性能。这在数据量大、写入频繁的场景下尤其明显。可读性差： 一串32位的十六进制字符，人类根本无法记忆或理解。
我的选择倾向：
对于单体应用、数据量可控、不需要跨库合并数据的场景，我几乎总是推荐使用自增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 employeesADD PRIMARY KEY (employee_id);-- 如果是复合主键（由多个列组成的主键）-- 假设 orders_items 表中，order_id 和 item_id 组合是唯一的ALTER TABLE order_itemsADD PRIMARY KEY (order_id, item_id);
一些需要注意的细节：
一个表只能有一个主键。 尽管它可以是复合主键，但逻辑上仍然是一个整体。主键列自动带有NOT NULL属性。 你不需要额外声明，但理解这一点很重要。添加主键约束可能需要时间。 对于数据量巨大的表，添加主键（尤其是需要检查唯一性并创建索引时）是一个耗时操作，可能会锁定表，影响线上业务。务必在低峰期或维护窗口进行。删除主键： 虽然不推荐轻易删除主键，但如果确实需要，可以使用 ALTER TABLE table_name DROP PRIMARY KEY;。但如果存在外键引用，你需要先删除或修改那些外键约束。
在实际项目中，我见过很多因为主键设计不当导致的问题，比如ID冲突、查询性能瓶颈、数据难以合并等等。所以，在数据库设计阶段，花时间思考并确定合适的主键策略，绝对是值得的投资。
以上就是数据库主键约束是什么？主键的设计、作用及设置指南的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/604179.html
微信扫一扫 
支付宝扫一扫 
