InnoDB在无显式主键时，优先选用第一个非空唯一索引，否则自动生成6字节隐藏列DB_ROW_ID作为聚簇索引键；该值全局共享、不可查、不可控，易引发复制延迟、并发争用与性能退化。
没有显式主键时，InnoDB到底在用什么当主键
当你建表时没写 PRIMARY KEY，InnoDB 会按顺序尝试：先找第一个 UNIQUE NOT NULL 索引；找不到，就自动生成一个隐藏列 DB_ROW_ID（也叫 _rowid），作为聚簇索引的键。这个值是 6 字节、全局共享、单点自增的整数，你无法查询、不能排序、不能加索引，更不能在 SQL 中引用。
隐藏主键导致复制延迟的典型场景
在基于行的复制（ROW-based replication）中，UPDATE 或 DELETE 如果没有主键，备库无法定位目标行，只能全表扫描匹配条件。例如：
UPDATE orders SET status = 'shipped' WHERE create_time < '2023-01-01';
如果 orders 表无主键，这条语句在备库可能触发千万级行扫描——不是因为语句慢，而是因为没主键就没高效定位能力。
- 主键缺失 → 二级索引叶子节点存的是
DB_ROW_ID，而非业务字段，回表路径不可控 - 所有无主键表共用同一
dict_sys->row_id计数器，高并发写入时出现 mutex 争用 -
SHOW CREATE TABLE和information_schema完全不暴露该列，运维排查时“看不见、查不到、改不了”
显式主键如何解决这些底层问题
显式定义主键不只是“满足语法要求”，它直接绑定数据物理组织方式。比如：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
CREATE TABLE logs ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, event_type VARCHAR(32), created_at DATETIME ) ENGINE=InnoDB;
这样做的实际收益包括：
- 主键值可预测、可排序、可分页，
ORDER BY id DESC LIMIT 20是稳定高效的 - 所有二级索引（如
INDEX idx_type (event_type)）叶子节点存的是id，回表路径清晰可控 - 主从复制、逻辑备份（mysqldump --single-transaction）、GTID 等机制都依赖主键做行级一致性保证
- MySQL 8.0.30+ 的 GIPK（Generated Invisible Primary Keys）虽能显式暴露
my_row_id，但仍是兜底方案，不能替代业务主键的设计意图
最容易被忽略的隐性成本：联合主键与隐藏主键的叠加效应
如果你用了联合主键（如 PRIMARY KEY (user_id, order_id)），又误删了主键定义，InnoDB 不会保留原联合字段的语义，而是直接切回 DB_ROW_ID —— 这意味着原本按用户维度局部聚集的数据，瞬间变成全局随机写入，WAL 日志膨胀、缓冲池命中率骤降、SSD 写放大加剧。
真正危险的不是“没主键”，而是“以为有主键，其实没有”——尤其在迁移旧表、导入 CSV、或 ORM 自动生成 schema 时，PRIMARY KEY 极易被遗漏或静默丢弃。
