InnoDB无主键时自动创建6字节隐藏_rowid作为聚簇索引键，不可见、不可查、不保证全局唯一，高并发下锁争抢致写入下降，溢出归零可能引发数据覆盖，ROW模式复制中从库需全表扫描定位行导致夯住，二级索引因存储_rowid而体积膨胀、缓存效率降低。
没主键时InnoDB会偷偷用_rowid当聚簇索引
不是报错或拒绝建表，而是InnoDB自动补一个6字节的隐藏列_rowid作为聚簇索引键。这个值不可见、不能查、不能在WHERE或ORDER BY里用，只在内部B+树组织数据时起作用。
它本质是全局共享计数器，所有无主键表共用同一个dict_sys->row_id变量，高并发插入时会争抢dict_sys->mutex锁，写入吞吐直接掉；更麻烦的是，它最大值为248−1（约281万亿），溢出后归零，可能引发重复_rowid导致数据覆盖——线上真出过。
DELETE/UPDATE在ROW模式下会让从库SQL线程卡死
这是最常被忽略但后果最严重的点：主库执行DELETE FROM t WHERE status = 0这类操作，binlog记录的是每行的前镜像；从库回放时，必须逐行比对所有字段才能定位到要删的那条记录——因为没有主键或唯一索引，没法走索引查找。
- 删10万行 → 从库做10万次全表扫描
- 表有500万行，单次扫描耗时0.08秒 → 总耗时≈22小时
-
SHOW PROCESSLIST里看到SQL线程长期卡在Deleting状态，Seconds_Behind_Master持续飙升
这不是慢，是逻辑上无法高效执行。临时解法是STOP SLAVE SQL_THREAD后加REPLICATE_IGNORE_TABLE跳过该表，但治标不治本。
二级索引体积暴增且查询变慢
InnoDB所有二级索引叶子节点存的不是行地址，而是对应行的主键值。没显式主键时，这个“主键值”就是6字节_rowid，但它无法压缩、不能复用业务语义，还强制所有二级索引都带上这6字节冗余。
对比一下：
- 显式
id BIGINT AUTO_INCREMENT主键 → 二级索引每条记录多存8字节 - 隐式
_rowid→ 每条记录多存6字节，但因不可控插入顺序，B+树高度更快上升，页分裂更频繁 - 如果主键是
VARCHAR(36)UUID → 实际多存至少40字节（含长度前缀），索引体积翻倍
结果就是buffer pool缓存效率下降，innodb_buffer_pool_reads明显升高，EXPLAIN里经常出现type: ALL——哪怕你建了其他索引，也救不了。
上线前必须检查information_schema里的主键缺失
别等出事再查。用这条SQL扫一遍实例里所有用户表：
SELECT table_schema, table_name
FROM information_schema.tables t
WHERE (table_schema, table_name) NOT IN (
SELECT table_schema, table_name
FROM information_schema.columns
WHERE column_key = 'PRI'
)
AND table_schema NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');
注意：这个查询会把“有唯一索引但没主键”的表也列出来，它们虽能避免_rowid，但复制和分库分表工具仍可能报错。真正安全的只有显式定义的PRIMARY KEY。
修复动作必须同步主从：先STOP SLAVE，主从都执行ALTER TABLE ... ADD COLUMN id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST，再START SLAVE。别指望只在主库加完就完事——从库没这个字段，后续DML照样失败。
