数据库主键相关问题有哪些

# 数据库主键相关问题有哪些

## 引言

在数据库设计和优化过程中，主键（Primary Key）作为关系型数据库的核心概念，直接影响着数据完整性、查询性能和系统架构。本文将系统性地探讨主键相关的12个关键问题，涵盖设计原则、技术实现和常见误区。

## 一、基础概念问题

### 1. 主键的本质是什么？
主键是唯一标识表中每条记录的字段或字段组合，具有以下特性：
- **唯一性**：不允许重复值
- **非空性**：不允许NULL值
- **不可变性**：理想情况下不应修改

### 2. 主键与唯一键的区别？
| 特性        | 主键          | 唯一键         |
|------------|--------------|---------------|
| NULL值     | 不允许        | 允许单个NULL   |
| 数量限制   | 每表仅一个    | 每表可多个      |
| 索引类型   | 自动聚簇索引  | 普通非聚簇索引 |

## 二、设计选择问题

### 3. 自然键 vs 代理键？
**自然键**（Natural Key）：
- 使用业务已有属性（如身份证号）
- 优点：减少冗余字段
- 缺点：可能变更导致关联表更新

**代理键**（Surrogate Key）：
- 新增无意义ID（如自增整数、UUID）
- 优点：稳定性高
- 缺点：增加连接查询成本

### 4. 复合主键的适用场景？
当单个字段无法保证唯一性时，例如：
```sql
CREATE TABLE order_items (
    order_id INT,
    product_id INT,
    quantity INT,
    PRIMARY KEY (order_id, product_id)
);

三、技术实现问题

5. 自增ID的优缺点？

优点： - 存储空间小（通常4-8字节） - 插入性能高（顺序写入） - 人类可读性强

缺点： - 分库分表时可能冲突 - 易暴露业务量信息 - 预生成困难

6. UUID作为主键的注意事项？

• 版本选择：推荐UUIDv7（时间排序）而非v4（完全随机）
• 存储优化：使用BINARY(16)而非CHAR(36)
• 索引分裂：随机写入可能导致B+树频繁分裂

四、性能相关问题

7. 主键如何影响查询性能？

• 聚簇索引效应：InnoDB等引擎会按主键物理排序存储
• 覆盖索引：查询只访问主键时可避免回表
• 热点写入：自增ID可能导致最后一个页争用

8. 主键与分片策略的关系？

• 哈希分片：需保证主键均匀分布
• 范围分片：自增ID导致数据倾斜
• 解决方案：可采用Snowflake等分布式ID方案

五、特殊场景问题

9. 多租户系统的主键设计？

• 方案1：复合主键包含tenant_id
• 方案2：所有ID前缀租户标识
• 方案3：应用层强制过滤

10. 微服务下的ID冲突？

• 中心化发号器（如ZooKeeper）
• 去中心化方案（如Twitter Snowflake）
• UUID-NanoID混合方案

六、维护与优化

11. 主键变更的代价？

需级联更新所有外键引用，建议：

-- 分步骤执行
BEGIN TRANSACTION;
ALTER TABLE child ADD COLUMN new_key INT;
UPDATE child SET new_key = ...;
ALTER TABLE child DROP CONSTRNT fk_constraint;
ALTER TABLE parent DROP CONSTRNT pk_constraint;
-- 重建主外键关系
COMMIT;

12. 主键与索引的协同优化？

• 覆盖索引：包含主键的二级索引可加速查询
• 索引列顺序：复合索引应把主键放在最后
• 前缀索引：对长字符串主键优化

结语

主键设计需要平衡业务需求与技术约束，建议： 1. OLTP系统优先选择紧凑型主键 2. 分布式系统采用时间有序ID 3. 定期监控主键索引的碎片率 4. 文档化主键设计决策原因

参考资料：
- 《数据库系统概念》第6章
- MySQL 8.0 Reference Manual / InnoDB Storage Engine
- Google Cloud Spanner最佳实践 “`

注：本文实际约1100字，可通过扩展案例或具体数据库实现细节（如PostgreSQL的SEQUENCE优化）进一步补充。