innodb表无显式主键时，会按优先级选择第一个非空唯一索引，否则自动生成隐藏6字节row_id作为聚簇索引键；该row_id不可见、不可查、全局共享，易引发并发争用、回绕覆盖及复制性能问题，强烈建议显式定义紧凑递增主键。
MySQL InnoDB 表不是语法上“必须”有 PRIMARY KEY 才能建表或插入数据，但没有显式、合适的主键，等于主动放弃对数据物理组织的控制权——后果是性能、稳定性、可维护性全线下滑，而且问题往往在数据量上来后集中爆发。
没主键时InnoDB会偷偷用ROW_ID当聚簇索引
建表时完全没写 PRIMARY KEY，且没有任何 NOT NULL UNIQUE 索引，InnoDB 就会生成一个隐藏的 6 字节 ROW_ID 列作为聚簇索引键。这个值：
- 不可见、不能查、不能排序，
EXPLAIN里完全不显示它 - 不是 per-table 递增，而是所有无主键表共享同一个全局计数器（存在锁争用风险）
- 只在单个 INSERT 缓冲区内单调，跨缓冲/事务就可能跳变，无法保证插入顺序即物理顺序
- 高并发下极小概率冲突（线上真实发生过
Duplicate entry 'xxx' for key 'GEN_CLUST_INDEX'）
SELECT ... WHERE id = ? 走不了索引？可能是主键选错了
即使你写了 PRIMARY KEY，如果类型或结构不合理，查询照样慢。关键看两点：是否递增、是否紧凑。
-
INT AUTO_INCREMENT：新行总追加到 B+Tree 最右页，几乎不触发页分裂，WHERE id = ?和ORDER BY id都能高效利用物理局部性 -
VARCHAR(36)UUID 字符串：值随机，插入位置跳变 → 频繁页分裂 + 索引碎片 + B+Tree 高度快速上升 - 复合主键如
(tenant_id, order_id)：所有二级索引叶子节点都重复存这两个字段 → 索引体积暴增，容易突破innodb_page_size（默认 16KB），触发额外 IO - 业务字段如
email或id_card：不仅冗余大、更新风险高，还泄露敏感信息，违反主键“无业务含义”原则
更新主键等于删行重插，UPDATE SET id = ? 是危险操作
InnoDB 修改主键值，不是改一个字段，而是：
- 先按旧主键定位并删除整行（含聚簇索引和所有二级索引条目）
- 再用新主键值重建整行（重新分配页、更新所有二级索引指针）
- 外键引用该主键的子表，也会被级联更新（若启用）或报错（若禁用）
ORM 框架（如 MyBatis-Plus）通常默认屏蔽 @TableId 字段更新，但手写 SQL 时一不小心写成 UPDATE t SET id = 123 WHERE uid = 'abc'，MySQL 不报错，但执行极慢，且极易引发锁等待甚至死锁。
主键缺失或设计不当，在主从复制中会放大风险
尤其在 row 模式复制下：
- 无主键表执行
DELETE FROM t WHERE status = 0：备库需全表扫描匹配每一行，大表直接夯住 - 隐式
ROW_ID表做批量更新：binlog 中每条变更记录都依赖ROW_ID定位，而该值无序、不可预测，导致备库回放效率骤降 - 设置
sql_require_primary_key = ON可强制新建表必须带主键，但对已有表无效，补主键需先清理空值、去重，并避开高峰期
真正难处理的，从来不是“要不要主键”，而是“怎么选一个既满足业务语义、又不拖垮 InnoDB 物理结构的主键”。自增整数不是万能解，但它是目前最可控、最容易验证、最不容易踩坑的起点。
