innodb必须有主键，因为聚簇索引直接决定数据物理存储顺序；无显式主键时，innodb会退化使用隐式rowid，该值不可见、不可控、不自增，导致随机写入、页分裂、二级索引膨胀及查询不可靠。
因为InnoDB表没主键时会用隐式ROWID做聚簇索引，但这个隐式主键不可见、不可控，且重启后可能变化；而显式自增主键能稳定控制数据物理存储顺序，避免页分裂和碎片。
为什么InnoDB必须有主键才能高效写入
InnoDB的聚簇索引直接决定数据在磁盘上的物理排列方式。没有显式PRIMARY KEY时，引擎会退化为使用第一个NOT NULL UNIQUE字段，若也没有，就用6字节隐式ROWID——这个值由InnoDB内部维护，不暴露给用户，也无法预测或干预。
- 隐式
ROWID不是自增的，插入顺序与ROWID增长不一致，实际仍是随机写入 - 隐式主键无法被二级索引引用，导致外键、关联查询、分页等场景行为不可靠
- 某些DBA工具或ORM框架依赖显式主键字段，缺失时可能报错或降级为全表扫描
AUTO_INCREMENT如何减少页分裂
页分裂发生在B+树节点满载却要插入新键值时，引擎需拆分页并重分配记录。自增主键让每次INSERT都落在索引最右侧叶子节点末尾，几乎不触发分裂。
- 非自增主键（如
UUID或业务流水号）导致数据随机落到任意位置，频繁引发页分裂和空间碎片 - 页分裂不仅耗CPU和IO，还会使
SELECT扫描更多页，降低缓存命中率 - 即使业务ID本身“看似有序”（如时间戳+序列），只要不是数据库严格递增生成，就无法保证InnoDB写入顺序
自增主键对二级索引的实际影响
InnoDB所有二级索引的叶子节点都存储对应行的主键值，而非行指针。主键越小，二级索引占用空间越少，缓存效率越高。
-
INT主键占4字节，BIGINT占8字节，而CHAR(36)的UUID占36字节——后者会让每个二级索引条目膨胀9倍 - 更大的索引意味着更少的键能放进内存页，查询时需要更多磁盘I/O
- 如果用复合主键（如
(tenant_id, order_no)），二级索引将重复存储全部字段，进一步放大开销
自增主键不是万能的，但缺它真不行
自增主键的缺陷（如分布式ID冲突、暴露数据量）是可绕过的问题；而没有主键带来的底层存储紊乱，是InnoDB自身机制决定的硬伤，没法靠应用层补救。
真正容易被忽略的是：哪怕你用UUID当主键，也得显式声明PRIMARY KEY——否则InnoDB仍会 fallback 到隐式ROWID，等于白设。自增只是最优解之一，但“必须有主键”这条底线，从来就没商量余地。
