根本原因是InnoDB索引组织表（IOT）强制依赖主键构建聚簇索引，无主键则无法确定数据物理存储顺序；若未显式定义，InnoDB会退而选用首个UNIQUE NOT NULL索引或自动生成不可控的隐藏_rowid，导致复制、备份、ORM等场景逻辑不一致与性能劣化。
MySQL建表时强制要求主键的根本原因
不是“建议”，而是InnoDB存储引擎的物理结构决定的——没有主键，数据就无法按B+树组织，聚簇索引就不存在。MySQL 8.0.26+虽默认启用sql_require_primary_key=ON，但真正起作用的不是这个参数，而是InnoDB底层对索引组织表（IOT）的硬性依赖。
没有主键时InnoDB怎么存数据
当建表语句里漏掉PRIMARY KEY，InnoDB会按顺序尝试：
- 找第一个定义为
UNIQUE NOT NULL的索引，把它当聚簇索引用 - 找不到就自动生成一个隐藏的
_rowid（6字节整数），但这个ID不对外暴露、不可查询、不能被外键引用 - 这个隐藏ID在表重建、导入导出、主从复制等场景下可能重排，导致逻辑不一致
换句话说，没显式主键 ≠ 没主键，只是你失去了控制权。
为什么sql_require_primary_key=ON会拦住ALTER操作
这个参数不是“加个开关”，而是在DDL执行过程中做原子性校验。比如想把单列主键改成复合主键：
-
ALTER TABLE t DROP PRIMARY KEY→ 表瞬间变成无主键状态 - 此时哪怕下一秒就执行
ADD PRIMARY KEY (a,b)，中间也存在一个“无主键窗口” -
sql_require_primary_key=ON会在DROP后立刻报错：ERROR 3750 (HY000): Unable to create or change a table without a primary key
绕过方法只有先关参数（不推荐），或改用带主键重建的原子操作（如CREATE TABLE ... SELECT + RENAME）。
业务上最容易忽略的三个后果
很多团队只记得“主键要快”，却踩在更隐蔽的坑里：
- 二级索引体积膨胀：每个二级索引项都存主键值作为回表依据；用UUID当主键，一个
VARCHAR(36)会让所有二级索引变大3–4倍 - UPDATE/DELETE在从库全表扫描：RBR模式下，从库靠主键定位行；没主键就只能扫全表匹配WHERE条件，延迟飙升
- ORM生成SQL失效：Django、Laravel、MyBatis等框架默认依赖主键字段做
save()、update()、delete()，没主键会抛异常或静默失败
最麻烦的是，这些问题往往上线后才爆发，且排查路径长——它不在SQL里，而在表结构定义那一行被忽略的PRIMARY KEY上。
