无主键表会怎样

在数据库里，“无主键表（没有 PRIMARY KEY 的表）”并不是不能建，但会带来一系列潜在问题和风险。下面从实际影响、典型场景和建议几个方面说明。

一、无主键表会怎样（主要影响）

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

• 没有主键 = 没有“唯一身份”
• 可能出现完全重复的行
• 更新 / 删除时容易“误伤多行”

UPDATE user SET status=1 WHERE name='Tom';
-- 如果有多个 Tom，会一起被改

2. 删除 / 更新只能靠“全行匹配”

没有主键时，常见写法是：

DELETE FROM log
WHERE col1='a' AND col2='b' AND col3='c';

问题：

• 条件写不全 → 删错
• 行完全一致 → 无法只删其中一条

3. 复制（主从同步）容易出问题

在 MySQL 主从复制中：

• 基于行的复制（ROW）依赖“能定位行”
• 无主键表可能导致：
  • 从库扫描全表
  • 复制延迟
  • 甚至数据不一致

官方明确建议：每张表都应有主键

4. 性能下降

• 主键通常伴随聚簇索引（InnoDB）
• 无主键时：
  • InnoDB 会自动生成隐藏 row_id
  • 索引结构不稳定
  • 查询、写入效率更差

5. ORM / 框架支持差

很多框架（如 Hibernate、MyBatis-Plus、JPA）：

• 强制要求 @Id
• 无主键表：
  • 无法做单条更新
  • 无法做对象映射
  • 代码很别扭

6. 数据质量难以保证

没有主键：

• 无法防止重复
• 无法做“存在即更新”
• 审计、回溯困难

二、哪些表“可以”没有主键？

以下情况相对可接受：

✅ 纯日志表（短期）

request_log
access_log

特点：

• 只插入，不更新
• 按时间清理
• 不依赖单行操作

但仍建议：

id BIGINT AUTO_INCREMENT PRIMARY KEY

✅ 临时表 / 中间表

• 内存表
• ETL 临时表
• 一次性分析表

✅ 多维宽表（数据仓库）

• 通常靠组合键或分区
• 但仍建议“业务唯一键”

三、如果已经有无主键表，怎么办？

方案 1：加自增主键（最推荐）

ALTER TABLE t ADD id BIGINT PRIMARY KEY AUTO_INCREMENT;

方案 2：用业务字段做联合主键

PRIMARY KEY (user_id, date)

方案 3：加隐藏唯一列

ADD uid CHAR(36) DEFAULT UUID();

四、一句话总结

无主键表 = 能跑，但容易乱、慢、难维护、易出事。

最佳实践：

• 几乎每张表都应有主键
• 优先：BIGINT AUTO_INCREMENT
• 业务表：加唯一约束防止重复

如果你有具体数据库（MySQL / PostgreSQL / Oracle）或表场景，我可以给你更针对性的建议。