没有主键会怎样

在数据库（尤其是关系型数据库，如 MySQL、PostgreSQL、Oracle 等）中，“没有主键（Primary Key）” 会带来一系列问题，影响数据完整性、性能和业务可靠性。下面从多个角度说明“没有主键会怎样”。

一、数据层面会出现的问题

1. 无法唯一标识一行数据

• 没有主键，就意味着没有办法保证某一行是唯一的
• 可能出现完全重复的数据
• 你无法准确地说：“我要更新 / 删除这一条，而不是那一条”

name    age
Tom     18
Tom     18   ← 无法区分是哪一条

2. 数据冗余和脏数据增加

• 重复插入难以被发现
• 清洗数据成本高
• 统计结果可能失真

二、业务层面的问题

3. 更新 / 删除容易出错

没有主键时：

• UPDATE 可能一次改多行
• DELETE 可能误删多行

DELETE FROM user WHERE name = 'Tom';
-- 如果有多条 Tom，全删了

4. 业务逻辑难以保证正确性

很多业务依赖“唯一身份”：

• 用户账号
• 订单号
• 商品 SKU

没有主键，业务逻辑很容易出问题。

三、性能和数据库机制层面的问题

5. 查询性能可能变差

• 很多数据库默认用主键来组织数据（聚簇索引）
• 没有主键：
  • 可能使用隐藏行号
  • 或全表扫描
• 大表查询、JOIN 效率明显下降

6. 索引使用受限

• 外键（FOREIGN KEY）必须指向主键或唯一键
• 没有主键：
  • 无法建立规范的外键关系
  • 表之间关系混乱

7. 主从复制可能出问题（MySQL 等）

• 某些复制模式依赖主键
• 没有主键时：
  • 从库可能整行比对
  • 复制延迟、性能差

四、框架和工具层面的问题

8. ORM 框架不好用

如：

• MyBatis
• Hibernate
• JPA
• Django ORM

它们通常假设：

• 有主键
• 能用 id 定位对象

没有主键会导致：

• 更新失败
• 缓存混乱
• 映射异常

五、什么时候“可以没有主键”？

极少情况可以接受：

• 纯日志表（只写不查、不更新）
• 临时表 / 中间表
• 数据 warehouse 的某些宽表（不推荐）

但即便如此，也建议至少有一个唯一标识字段。

六、最佳实践建议

✅ 每张表都应有主键
✅ 优先使用：

• 自增 ID（BIGINT AUTO_INCREMENT）
• 或业务唯一键（如订单号）

CREATE TABLE user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) UNIQUE
);

总结一句话

没有主键的表，就像没有身份证的人：能存在，但处处不方便，还容易出乱子。

如果你愿意，可以告诉我：

• 用的是哪种数据库（MySQL / PostgreSQL / Oracle）
• 是设计新表，还是已有表出问题

我可以给你更具体的建议或改表方案。