MySQL InnoDB表虽语法不强制主键，但无显式主键时InnoDB会选用UNIQUE NOT NULL列或生成6字节隐藏_rowid作为聚簇索引，导致排序不可控、页分裂频繁、二级索引膨胀、查询变慢甚至全表扫描；_rowid全局共享、非自增、达2^48-1后归零，高并发下锁争抢且可能覆盖旧数据。
MySQL InnoDB 表不是语法上强制要求 PRIMARY KEY，但没有显式主键，等于把数据物理组织权交给 InnoDB 自行决定——而它选的方案（_rowid）在绝大多数生产场景下都会拖垮性能、放大风险。
没主键时 InnoDB 怎么选聚簇索引
InnoDB 必须有聚簇索引，这是它的存储前提。当建表时没写 PRIMARY KEY，它按顺序尝试：
- 第一个
UNIQUE NOT NULL列（哪怕你本意只是加个唯一约束） - 找不到就生成隐藏的 6 字节
_rowid，全局共享、不可见、不可查、不保证唯一
这个 _rowid 不是自增 ID 那种可控递增，而是所有无主键表共用一个计数器，高并发插入时会争抢 dict_sys->mutex，出现锁瓶颈；达到 2^48−1 后归零，可能覆盖旧数据。
为什么没主键会导致查询变慢甚至全表扫描
根本原因不是“没索引”，而是聚簇索引失效导致二级索引失去意义：
- 所有二级索引叶子节点存的是主键值 —— 没显式主键，就只能存
_rowid（6 字节） -
_rowid和物理存储位置无序，查一条记录要先走二级索引拿到_rowid，再回表随机 IO 查磁盘页 -
EXPLAIN显示key: NULL或type: ALL，不是没建索引，是索引根本没法高效定位数据 -
innodb_buffer_pool_reads持续升高，说明大量缓存未命中、频繁读盘
主键选错比没主键更危险
即使加了 PRIMARY KEY，类型选错一样引发连锁问题：
-
INT AUTO_INCREMENT：最优。写入追加、页分裂少、二级索引体积小（4 字节） -
VARCHAR(36) UUID：灾难。值完全随机，B+Tree 高度快速上升，插入时频繁页分裂 + 碎片，二级索引体积膨胀近 10 倍 -
(tenant_id, created_at)复合主键：若tenant_id区分度低（比如 SaaS 租户 90% 是同一客户），范围查询仍需扫大量无效页 - 用邮箱、身份证等业务字段当主键：值可能变更 → 更新主键 = 全行重建 + 所有二级索引重写
如何验证当前表是否掉进隐式主键陷阱
别只看 SHOW CREATE TABLE，得确认实际生效的聚簇索引键：
- 执行
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME = 'db/tbl';，检查ROW_FORMAT和ZIP_PAGE_SIZE之外的隐含线索 - 更直接：运行
SELECT COUNT(*), page_no FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME = 'db/tbl' GROUP BY page_no ORDER BY COUNT(*) DESC LIMIT 5;—— 如果热点页分布极度离散，大概率是_rowid导致数据无序写入 - 用
mysqlpump或mysqldump --skip-triggers --no-create-info导出数据，观察 INSERT 语句是否含主键字段 —— 隐式_rowid不会出现在 dump 中
最隐蔽的坑在于：问题往往在写入量上来之后才爆发，而那时再补主键已需锁表或停写，代价远高于建表时多敲几个字。
