innodb表虽非强制要求显式主键，但无主键时会自动生成隐藏6字节row_id作为聚簇索引键，该值不可见、不可查、不保证全局唯一，易引发高并发冲突、慢查询误判、备库夯住等问题；主键决定数据物理存储顺序，自增整数主键可避免页分裂、减少随机io、提升缓存效率，而uuid或复合主键会导致索引膨胀、性能下降；更新主键等于全行重建，必须禁止。
MySQL InnoDB 表不是“必须有主键”才能运行，但没有显式主键，就等于把索引组织权交给了 MySQL 自己决定——而它选的方案（ROW_ID）几乎总是更差。
没主键时InnoDB会偷偷用ROW_ID当聚簇索引
建表时完全不写 PRIMARY KEY，且没有任何 NOT NULL UNIQUE 索引，InnoDB 就会生成一个隐藏的 6 字节 ROW_ID 列作为聚簇索引键。这个值不可见、不能查、不能排序，只在单个 INSERT 缓冲区内单调递增。
-
ROW_ID不保证全局唯一，高并发下有极小概率冲突（虽罕见，但线上出过） -
EXPLAIN看不到它，慢查询分析时容易误判“为什么没走索引” - 它无法被外键引用，也无法用于
ORDER BY或分页优化 - 主从复制中，
ROW_ID表在 row 模式下可能引发备库夯住（尤其大事务删除）
主键决定聚簇索引物理顺序，直接影响INSERT和SELECT性能
InnoDB 的数据行就存放在聚簇索引的叶子节点里。主键值就是聚簇索引的键，决定了数据在磁盘上的物理排列方式。
- 自增整数主键 → 新行总追加到 B+ 树末尾 → 几乎不触发页分裂，写入快、缓存友好
- UUID 字符串主键 → 值随机分布 → 新行插入位置跳变 → 频繁页分裂 + 随机 IO + 索引碎片
- 复合主键（如
(tenant_id, order_id)）→ 所有二级索引叶子节点都重复存这两个字段 → 索引体积暴增，缓存命中率下降 -
ORDER BY id查询快不快，取决于物理顺序是否与逻辑顺序一致；无序主键下，这句很可能变成全表扫描
二级索引依赖主键值，主键越长，索引开销越大
InnoDB 所有二级索引（INDEX）的叶子节点，存的不是行地址，而是对应行的主键值。这意味着：主键是所有索引的“共享成本”。
- 主键是
VARCHAR(32)→ 每条二级索引记录多存至少 32 字节（含长度前缀） - 主键是
BIGINT（8 字节）→ 同样一条索引记录，体积小得多，一页能存更多索引项，减少 IO - 外键约束会让子表索引也继承全部主键列 → 冗余被放大，极易突破
innodb_page_size（默认 16KB），触发额外页分裂
更新主键 = 全行重建，千万别手写UPDATE ... SET id = ?
InnoDB 修改主键值，不是改一个字段，而是删除旧行 + 插入新行：聚簇索引要挪动数据，所有二级索引都要同步更新指针。
- ORM（如 MyBatis-Plus）默认禁用
@TableId字段更新，但手写 SQL 时可能误写SET id = ?，MySQL 不报错，但执行极慢 -
ALGORITHM=INSTANT对主键更新无效 —— 这是存储引擎硬限制，绕不过 - 业务真需要“ID 合并”或“记录迁移”？应走逻辑标记（如
redirect_id）+ 应用层路由，而非直接 UPDATE 主键
真正容易被忽略的点是：主键设计不是建表时点一下的事，它决定了后续所有索引的空间效率、所有写入的 IO 模式、所有关联查询的成本结构。哪怕表当前只有几千行，一旦主键定错，后期扩容时代价远超重命名字段或加索引——你得重建整个聚簇索引树。
