1. 主键外键设计实战指南：数据库关系的核心基石
刚入行那会儿，我最怕在数据库设计评审时被问到"这个外键引用合理吗？"——直到有次线上事故让我彻底理解了主外键的本质。当时某个订单表的用户ID字段没设外键约束，结果清理僵尸账号时直接导致上万条订单数据变成"无主孤儿"。今天我们就来聊聊这个用血泪教训换来的主题：如何像老司机一样设计主键和外键。
主键（Primary Key）是数据库表的身份证号，保证每条记录的唯一性；外键（Foreign Key）则是表之间的血缘关系证明。它们共同构建了关系型数据库的完整性与一致性体系。下面这个对比表能帮你快速抓住核心差异：
| 特性 | 主键 | 外键 |
|---|---|---|
| 唯一性 | 绝对唯一 | 允许重复 |
| 空值 | 不允许NULL | 可允许NULL |
| 数量 | 每表仅一个 | 每表可多个 |
| 功能 | 唯一标识记录 | 关联其他表的主键 |
| 索引 | 自动创建唯一索引 | 通常自动创建普通索引 |
2. 主键设计：不只是唯一标识那么简单
2.1 主键类型选型实战
主键设计就像给数据库表选身份证，常见的有三种方案：
自增整数（经典之选）
CREATE TABLE employees ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL );提示：MySQL的AUTO_INCREMENT、PostgreSQL的SERIAL、Oracle的SEQUENCE都属此类
自然键（业务属性作为主键）
CREATE TABLE countries ( country_code CHAR(2) PRIMARY KEY, -- 如'CN','US' country_name VARCHAR(100) NOT NULL );UUID（分布式系统首选）
CREATE TABLE distributed_systems ( system_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), config JSONB NOT NULL );我在金融系统里踩过的坑：曾用手机号作为用户表自然键，结果遇到用户换号需求时，需要级联更新7个关联表。自那以后，我的设计原则变成："主键就该是毫无业务意义的代理键"。
2.2 复合主键的特殊场景
订单明细表是经典案例：
CREATE TABLE order_items ( order_id INT NOT NULL, product_id INT NOT NULL, quantity INT CHECK (quantity > 0), PRIMARY KEY (order_id, product_id), FOREIGN KEY (order_id) REFERENCES orders(id), FOREIGN KEY (product_id) REFERENCES products(id) );这里(order_id, product_id)组合才能唯一确定一条记录。但注意：使用复合主键时，所有外键引用必须包含全部主键列。
3. 外键设计：表关系的桥梁与守卫
3.1 外键约束的四种武器
1. 级联删除（ON DELETE CASCADE）
CREATE TABLE order_payments ( id SERIAL PRIMARY KEY, order_id INT REFERENCES orders(id) ON DELETE CASCADE, amount DECIMAL(10,2) NOT NULL );当主表(orders)记录删除时，自动删除关联的从表(order_payments)记录。适合"主子"型强关联关系。
2. 设为NULL（ON DELETE SET NULL）
CREATE TABLE employee_devices ( id SERIAL PRIMARY KEY, employee_id INT REFERENCES employees(id) ON DELETE SET NULL, device_serial VARCHAR(50) UNIQUE );主表记录删除时，从表外键置为NULL。适用于可选关联关系。
3. 禁止删除（ON DELETE RESTRICT）默认行为。主表记录有关联从表记录时，阻止删除操作。
4. 无操作（ON DELETE NO ACTION）类似RESTRICT，但检查时机略有不同（在语句执行后检查）。
3.2 外键索引的隐藏规则
大多数数据库会自动为外键创建索引，但有些场景需要手动优化：
-- PostgreSQL中手动为外键添加特定类型索引 CREATE INDEX CONCURRENTLY idx_order_items_product_id ON order_items (product_id) INCLUDE (quantity);注意：外键字段上的低效索引会导致级联操作性能雪崩。曾有个UPDATE操作因缺失合适索引，从10ms暴增到8s。
4. 实战避坑指南：来自生产环境的经验
4.1 主键设计七大禁忌
- 不要用可变字段：如邮箱、手机号等可能变更的业务属性
- 不要用超大字段：如TEXT类型做主键，索引效率极低
- 避免GUID无序性：随机UUID会导致索引碎片，考虑有序UUIDv7
- 复合主键别超3列：过多列会显著降低连接性能
- 小心序列溢出：INT自增在21亿左右会溢出，大系统用BIGINT
- 分布式ID需谨慎：雪花ID要考虑服务器时钟回拨问题
- 别忽略时区问题：用时间戳做主键时确保时区统一
4.2 外键性能优化三招
1. 延迟约束检查（DEFERRABLE）
-- PostgreSQL示例 BEGIN; SET CONSTRAINTS ALL DEFERRED; -- 先插入从表再插入主表 COMMIT;2. 批量操作临时禁用外键
-- MySQL批量导入优化 SET FOREIGN_KEY_CHECKS = 0; -- 执行大批量导入 SET FOREIGN_KEY_CHECKS = 1;3. 级联操作监控方案
-- 记录级联删除影响的记录数 CREATE OR REPLACE FUNCTION log_cascade_deletes() RETURNS TRIGGER AS $$ BEGIN INSERT INTO deletion_audit VALUES (TG_TABLE_NAME, OLD.id, NOW()); RETURN OLD; END; $$ LANGUAGE plpgsql;5. 特殊场景解决方案
5.1 无外键关联的替代方案
当数据库不支持外键（如某些NoSQL）或需要跨数据库关联时：
空间包含关系（PostGIS示例）
-- 通过空间位置关联店铺与区域，无需外键 SELECT s.store_name FROM stores s, sales_regions r WHERE ST_Contains(r.geom, s.location);触发器维护一致性
CREATE TRIGGER validate_department BEFORE INSERT OR UPDATE ON employees FOR EACH ROW EXECUTE FUNCTION check_department_exists();5.2 主键与索引的微妙关系
虽然主键自动创建唯一索引，但两者有本质区别：
| 比较维度 | 主键 | 索引 |
|---|---|---|
| 唯一性 | 必须唯一 | 可不唯一 |
| NULL值 | 不允许 | 通常允许 |
| 数量限制 | 每表一个 | 每表多个 |
| 表设计意义 | 逻辑模型核心 | 物理优化手段 |
| 聚类特性 | 通常是聚类索引 | 普通索引非聚类 |
6. 经典案例：员工管理系统设计
让我们用完整的员工部门模型收尾：
-- 部门表（主表） CREATE TABLE departments ( dept_id SERIAL PRIMARY KEY, dept_name VARCHAR(100) NOT NULL UNIQUE, budget DECIMAL(15,2) CHECK (budget >= 0) ); -- 员工表（从表） CREATE TABLE employees ( emp_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), dept_id INTEGER REFERENCES departments(dept_id) ON DELETE SET NULL ON UPDATE CASCADE, name VARCHAR(100) NOT NULL, salary DECIMAL(10,2) CHECK (salary > 0), CONSTRAINT unique_employee UNIQUE (dept_id, name) ); -- 自动为外键创建索引（PostgreSQL语法） CREATE INDEX ON employees (dept_id);这个设计体现了几个关键点：
- 使用UUID避免自增ID的可预测性
- ON DELETE SET NULL允许保留离职员工记录
- ON UPDATE CASCADE确保部门ID变更自动传播
- 复合唯一约束防止部门内重名
- 显式创建外键索引优化查询性能