innodb强烈建议必须加主键，因为其为索引组织表，聚簇索引必须存在且唯一；无显式主键时mysql会优先选用not null unique索引，否则自动生成不可见、不唯一、高并发易冲突的6字节row_id，导致性能下降、复制异常及优化困难。
InnoDB 表不是语法上“必须”有主键才能建表或插入数据，但没有显式主键，就等于把索引组织权交给了 MySQL 自己决定——而它选的方案（ROW_ID）几乎总是更差。
为什么 InnoDB 没主键也能运行，却强烈建议必须加？
InnoDB 是索引组织表（IOT），数据行直接存放在聚簇索引的叶子节点里。这个聚簇索引必须存在，且只能有一个。
- 你显式定义了
PRIMARY KEY→ 它就是聚簇索引 - 你没定义主键，但有
NOT NULL UNIQUE索引 → InnoDB 会悄悄拿它当聚簇索引（不推荐，尤其该列是字符串或 UUID） - 你既没主键也没合适唯一索引 → InnoDB 自动生成隐藏的 6 字节
ROW_ID列作为聚簇索引键
问题在于：ROW_ID 不可见、不可查、不保证全局唯一、不能用于 ORDER BY 或分页，且高并发下有极小概率冲突。EXPLAIN 也看不到它，慢查询分析时容易误判“为什么没走索引”。
MyISAM 为什么真能没有主键？
MyISAM 是堆组织表（Heap-organized），数据按插入顺序物理存放，索引只存数据行在 .MYD 文件里的偏移地址，跟主键完全无关。
- 没主键 → 索引依然能建，查完索引直接跳地址读数据
- 没索引 → 就全表扫描，但语法上完全合法
- 某些旧 ORM 或客户端会因“无主键”误判排序/分页稳定性，但这属于上层逻辑问题，不是 MyISAM 本身报错
也就是说：MyISAM 的索引和数据是分离的，主键只是个可选约束；而 InnoDB 的主键 = 数据存储结构本身。
不加主键的实际代价有哪些？
表面看建表、插入、简单查询都正常，但隐患藏在底层：
- 所有二级索引的叶子节点都得存一遍主键值 —— 如果用
UUID或复合字段当主键，索引体积暴增，buffer pool 命中率下降 - INSERT 性能受损：
ROW_ID在单个 INSERT buffer 内递增，跨 buffer 可能乱序；自增整数主键则总追加到 B+ 树末尾，页分裂极少 - UPDATE 主键 = 全行重建 + 所有二级索引更新 → 必须禁止
- 主从复制中，
ROW_ID表在 row 模式下可能引发备库夯住（尤其大事务 DELETE）
一个典型现象：EXPLAIN 显示 type=ref 但 Extra 出现 Using index condition，说明走了索引下推但仍要回表 —— 这时如果 SELECT 字段都在索引里，本可建覆盖索引，却因主键设计不合理白白多一次 B+ 树查找。
迁移或新建表时最容易忽略的一点
把老 MyISAM 表转成 InnoDB 时，很多人只执行 ALTER TABLE t ENGINE=InnoDB，却忘了加主键。结果表结构看着一样，实际已埋下性能地雷：InnoDB 用 ROW_ID 替代了原本 MyISAM 的自然插入顺序，写入随机性陡增，缓存效率断崖下跌。
真正安全的做法是：迁移前先确认有显式 PRIMARY KEY，没有就加一个自增 id 列，并设为 PRIMARY KEY —— 不是“可选优化”，而是避免 InnoDB 底层机制失控的底线操作。
