MySQL表不能没有主键：原因、危害与主从架构问题-平芜编程栈

文章目录

MySQL表不能没有主键：原因、危害与主从架构问题
- 前言
- 一、InnoDB 的索引组织表（IOT）
- 二、没有主键时 InnoDB 的处理方式
- - 1. 选择第一个 UNIQUE NOT NULL 的索引
  - 2. 如果没有合适的唯一索引，自动生成隐藏的 _rowid
- 三、没有显式主键的危害
- - 危害一：无法使用覆盖索引优化
  - 危害二：二级索引膨胀
  - 危害三：数据物理排列无序，产生大量随机 I/O
  - 危害四：无法高效执行 `REPLACE INTO` 和 `INSERT ... ON DUPLICATE KEY UPDATE`
  - 危害五：ORM 框架和工具链的兼容性问题
- 四、主从复制架构中的严重问题
- - 问题一：Row-Based Replication（RBR）性能严重下降
  - 问题二：从库回放 UPDATE/DELETE 时全表扫描
  - - 并行复制（MTS）对无主键表的回放是否有作用？
  - 问题三：数据不一致风险增大
  - 问题四：并行复制（MTS）效率降低
  - 问题五：半同步复制和组复制的风险
- 五、最佳实践
- - 1. 每张表必须有显式主键
  - 1.1 MySQL 8.0.26+ 安全网：自动生成不可见主键
  - 2. 推荐使用自增整数作为主键
  - 3. 分布式场景的主键方案
  - 4. 检查现有表是否缺少主键
- 六、总结

MySQL表不能没有主键：原因、危害与主从架构问题

前言

在 MySQL 的建表规范中，“每张表必须有主键"几乎是所有大厂开发规范中的第一条铁律。但很多人只知道"要加主键”，却不理解背后的深层原因。本文从 InnoDB 存储引擎的底层原理出发，详细说明为什么 MySQL 表不能没有主键，缺少主键会带来哪些危害，以及在主从复制架构中可能引发的严重问题。

一、InnoDB 的索引组织表（IOT）

理解主键的重要性，首先要理解 InnoDB 的表组织方式。

InnoDB 采用索引组织表（Index Organized Table）的模式，即表中的数据按照主键的顺序存储在 B+ 树的叶子节点中。这张以主键为索引的 B+ 树被称为聚簇索引（Clustered Index）。

聚簇索引（主键 B+ 树） ┌─────────────────────────────────────────┐ │ 非叶子节点 │ │ (存储主键值 + 指针) │ ├─────────────────────────────────────────┤ │ 叶子节点：存储完整的行数据 │ │ 按主键顺序物理排列 │ └─────────────────────────────────────────┘

主键是数据在磁盘上物理排列的依据。如果没有主键，InnoDB 就无法确定数据的物理存储顺序，这是所有问题的根源。

二、没有主键时 InnoDB 的处理方式

如果建表时没有指定主键，InnoDB 会按以下顺序尝试选择一个替代方案：

1. 选择第一个 UNIQUE NOT NULL 的索引

CREATETABLEt1(idBIGINTNOTNULLUNIQUE,nameVARCHAR(50));-- InnoDB 会使用 id 作为聚簇索引键

2. 如果没有合适的唯一索引，自动生成隐藏的 _rowid

InnoDB 会自动创建一个 6 字节（48 位）的隐藏列DB_ROW_ID，作为聚簇索引的键。

CREATETABLEt2(nameVARCHAR(50),ageINT);-- 没有任何索引，InnoDB 自动生成 DB_ROW_ID-- 可通过 SELECT _rowid FROM t2 查看（部分版本支持）

这个隐藏的_rowid就是大多数问题的根源。需要特别注意：所有没有主键的表共享同一个全局自增计数器（dict_sys->row_id），高并发写入时存在 mutex 锁竞争，成为性能瓶颈。

三、没有显式主键的危害

危害一：无法使用覆盖索引优化

没有主键时，所有二级索引的叶子节点存储的是_rowid（而非业务字段），查询无法通过二级索引直接获取数据，必须回表。

-- 有主键的情况CREATETABLEorders(order_idBIGINTPRIMARYKEY,user_idBIGINT,amountDECIMAL(10,2),INDEXidx_user_id(user_id));-- SELECT order_id, user_id FROM orders WHERE user_id = 100-- 可以通过 idx_user_id 的叶子节点直接拿到 order_id（主键），无需回表-- 没有主键的情况CREATETABLEorders_no_pk(user_idBIGINT,amountDECIMAL(10,2),INDEXidx_user_id(user_id));-- 同样的查询，必须回表到聚簇索引（_rowid）才能拿到完整行数据

危害二：二级索引膨胀

InnoDB 的二级索引叶子节点存储的是主键值。主键越长，二级索引占用的空间越大。

如果主键是BIGINT（8 字节），每个二级索引条目额外存储 8 字节
如果没有主键，使用_rowid（6 字节），看起来更小——但这意味着你完全失去了对索引大小的主动控制

更严重的是，如果你错误地选择了一个长字段（如VARCHAR(255)的 UUID）作为主键，所有二级索引都会被严重膨胀。

-- 反例：用 UUID 做主键CREATETABLEbad_example(idCHAR(36)PRIMARYKEY,-- 36 字节nameVARCHAR(50),INDEXidx_name(name));-- idx_name 的每个条目都要额外存储 36 字节的主键值-- 相比 BIGINT 主键，索引膨胀 4.5 倍

危害三：数据物理排列无序，产生大量随机 I/O

没有主键时，数据按_rowid的生成顺序存储，而非业务逻辑顺序。这意味着：

范围查询无法利用物理相邻性，产生大量随机磁盘 I/O
批量插入时可能频繁触发页分裂（Page Split）
数据碎片化严重，OPTIMIZE TABLE也无法根治

-- 有主键且自增，顺序插入，磁盘 I/O 友好CREATETABLElogs(idBIGINTAUTO_INCREMENTPRIMARYKEY,log_timeDATETIME,messageTEXT);-- 没有主键，插入顺序不可控，碎片化严重CREATETABLElogs_no_pk(log_timeDATETIME,messageTEXT);

危害四：无法高效执行`REPLACE INTO`和`INSERT ... ON DUPLICATE KEY UPDATE`

这两个语句依赖主键或唯一索引来判断"重复"。没有主键时，行为不可预期。

危害五：ORM 框架和工具链的兼容性问题

绝大多数 ORM 框架（Hibernate、MyBatis-Plus、Django ORM）都要求表有主键才能正常工作。没有主键会导致：

无法使用save()/update()等便捷方法
代码生成工具无法生成实体类
数据库迁移工具报错

此外，常用的运维工具也依赖主键：

pt-table-checksum/pt-table-sync（Percona Toolkit）强制要求表有主键
pt-online-schema-change在线 DDL 工具依赖主键进行数据拷贝
mysqldump逻辑备份在无主键时效率降低

四、主从复制架构中的严重问题

没有主键在主从复制场景下会引发一系列严重问题，这是生产环境中最大的隐患。

问题一：Row-Based Replication（RBR）性能严重下降

MySQL 推荐使用 Row-Based Replication（binlog_format=ROW）。在 RBR 模式下，UPDATE 和 DELETE 操作需要在 binlog 中记录被修改行的前后镜像，用于在从库上定位和执行相同的行。

有主键时：binlog 只需记录主键值即可定位行，数据量小，效率高。

-- 有主键，binlog 记录：-- UPDATE t SET name='new' WHERE pk=123-- 只需记录主键值 123

没有主键时：binlog 必须记录所有列的值来定位行，因为没有其他方式唯一标识一行。

-- 没有主键，binlog 记录：-- UPDATE t SET name='new'-- WHERE col1='xxx' AND col2='yyy' AND col3='zzz' ...-- 必须记录所有列的前镜像和后镜像

这会导致：

binlog 体积暴增：每个 DML 操作的 binlog 量可能是有主键情况下的 2-10 倍
网络带宽消耗增大：主从之间的 binlog 传输量大幅增加
从库回放延迟：从库 SQL 线程需要解析更多数据，复制延迟增大

问题二：从库回放 UPDATE/DELETE 时全表扫描

在从库上执行UPDATE或DELETE时，如果没有主键，从库无法精确定位要修改的行，可能退化为全表扫描。

-- 主库执行UPDATEusersSETstatus=1WHEREemail='test@example.com';-- 如果 users 表有主键，从库通过 binlog 中的主键值直接定位行-- 如果 users 表没有主键，从库需要扫描整张表来找到匹配的行-- 大表场景下，这可能导致从库延迟数分钟甚至数小时

可以通过slave_rows_search_algorithms参数控制从库搜索行的方式：

算法	说明
`INDEX_SCAN`	使用索引查找（有主键时首选）
`TABLE_SCAN`	全表扫描（最慢，无主键时的兜底）
`HASH_SCAN`	哈希查找（无主键时比全表扫描快）

-- 查看当前设置SHOWVARIABLESLIKE'slave_rows_search_algorithms';-- 设置为优先使用索引，其次哈希SETGLOBALslave_rows_search_algorithms='INDEX_SCAN,HASH_SCAN';

HASH_SCAN可以显著改善无主键表在从库的回放性能，但仍不如有主键的情况。

并行复制（MTS）对无主键表的回放是否有作用？

有作用，但效果有限，且存在上限。

MySQL 5.7+ 的并行复制（Multi-Threaded Slave）工作在事务级别——多个 worker 线程可以同时执行不同的事务。但无主键表的性能瓶颈在于每个 DML 操作本身的全表扫描开销，这是并行复制无法消除的。

具体分析：

场景	并行复制是否有帮助	说明
多个事务操作不同表	有帮助	不同表的事务可以并行执行，互不影响
多个事务操作同一张无主键表	帮助有限	全表扫描本身耗时长，并行执行多个全表扫描反而可能加剧磁盘 I/O 争用
多个事务操作同一行	无帮助	行级冲突导致必须串行执行，并行度降为 1

-- 假设从库有两个 worker 线程，同时收到两个事务：-- 事务1：UPDATE no_pk_table SET col=1 WHERE id=100 -- 需要全表扫描-- 事务2：UPDATE no_pk_table SET col=2 WHERE id=200 -- 需要全表扫描-- 有主键：两个事务通过主键定位行，各自 O(logN)，可以快速并行完成-- 无主键：两个事务各自触发全表扫描，磁盘 I/O 互相竞争，并行收益被抵消

结论：并行复制解决的是"事务间的并行度"问题，而无主键的瓶颈是"单个事务的执行效率"问题。两者是不同维度，不能互相替代。先加主键，再谈并行复制。

问题三：数据不一致风险增大

没有主键时，主从之间的数据一致性更难保证：

场景一：重复行问题

-- 没有唯一约束的表CREATETABLElogs_no_pk(log_timeDATETIME,messageVARCHAR(200));-- 插入两条完全相同的行INSERTINTOlogs_no_pkVALUES('2026-06-07 10:00:00','test');INSERTINTOlogs_no_pkVALUES('2026-06-07 10:00:00','test');-- 在主库上 DELETE 其中一条-- 从库无法区分要删除哪一条，可能删错行，导致主从数据不一致

场景二：GTID 模式下的冲突

在 GTID 复制模式下，每个事务都有全局唯一的 GTID。如果没有主键，事务在从库上重放时可能因为无法精确定位行而产生冲突，导致复制中断。

问题四：并行复制（MTS）效率降低

MySQL 5.7+ 支持基于逻辑时钟的并行复制（slave_parallel_type=LOGICAL_CLOCK）。并行复制的核心是判断事务之间是否存在冲突，而冲突判断依赖于行的唯一标识。

没有主键时：

无法高效判断两个事务是否操作同一行
并行复制的并发度降低，从库回放速度下降
在高写入场景下，从库延迟会显著增大

问题五：半同步复制和组复制的风险

在半同步复制（Semi-Sync Replication）和组复制（Group Replication）中，数据一致性要求更高：

半同步复制：主库等待至少一个从库确认收到 binlog 才返回。没有主键时，binlog 体积增大，确认延迟增大，主库写入性能下降。
组复制：组内成员之间通过行的唯一标识来检测冲突。没有主键时，冲突检测效率降低，可能导致事务回滚率上升。

五、最佳实践

1. 每张表必须有显式主键

CREATETABLEexample(idBIGINTNOTNULLAUTO_INCREMENTPRIMARYKEY,-- 业务字段created_atDATETIMEDEFAULTCURRENT_TIMESTAMP);

1.1 MySQL 8.0.26+ 安全网：自动生成不可见主键

MySQL 8.0.26 引入了sql_generate_invisible_primary_key参数。开启后，对于没有主键的表，MySQL 会自动创建一个不可见的主键列（my_row_id），作为兜底措施。

-- 查看当前设置SHOWVARIABLESLIKE'sql_generate_invisible_primary_key';-- 开启（建议在无法强制所有表加主键的场景下开启）SETGLOBALsql_generate_invisible_primary_key=ON;

注意：这只是安全网，不应替代显式主键。自动生成的不可见主键无法被应用层使用，且列名固定为my_row_id。

2. 推荐使用自增整数作为主键

主键类型	优点	缺点	适用场景
`AUTO_INCREMENT BIGINT`	顺序插入、索引紧凑、范围查询友好	分布式环境需要额外方案	单库场景首选
雪花算法 ID	分布式唯一、趋势递增	非严格自增，可能有少量乱序	分布式场景
UUID	全局唯一、无需协调	36字节、完全随机、索引膨胀严重	不推荐做主键

3. 分布式场景的主键方案

-- 方案一：使用 BIGINT 自增 + 步长-- 节点1：auto_increment_offset=1, auto_increment_increment=3-- 节点2：auto_increment_offset=2, auto_increment_increment=3-- 方案二：使用雪花算法生成的 BIGINT ID（推荐）CREATETABLEdistributed_table(idBIGINTNOTNULLPRIMARYKEY,-- 由应用层雪花算法生成-- 业务字段);-- 方案三：使用 MySQL 8.0 的窗口函数生成行号（仅做参考，不推荐）

4. 检查现有表是否缺少主键

-- 查找没有主键的表SELECTt.TABLE_SCHEMA,t.TABLE_NAMEFROMinformation_schema.TABLEStLEFTJOINinformation_schema.TABLE_CONSTRAINTS tcONt.TABLE_SCHEMA=tc.TABLE_SCHEMAANDt.TABLE_NAME=tc.TABLE_NAMEANDtc.CONSTRAINT_TYPE='PRIMARY KEY'WHEREtc.CONSTRAINT_NAMEISNULLANDt.TABLE_SCHEMANOTIN('mysql','information_schema','performance_schema','sys')ANDt.TABLE_TYPE='BASE TABLE';

六、总结

维度	有主键	无主键
数据定位	精确定位，O(logN)	回退为`_rowid`，不可控
索引大小	可控（主键越小越好）	膨胀或不可控
物理存储	顺序排列，I/O 友好	无序，碎片化严重
binlog 体积	小（仅记录主键）	大（记录所有列）
主从延迟	低	高（可能数小时）
数据一致性	强（行唯一标识）	弱（重复行风险）
并行复制	高效	效率降低
ORM 兼容	完全兼容	大量问题

一句话总结：主键不只是一个约束，它是 InnoDB 存储引擎的核心机制。没有主键的表就像没有地址的房子——快递员（复制线程）永远找不到门。

MySQL表不能没有主键：原因、危害与主从架构问题

文章目录