拥有内部自增ID与后端UUID7二级ID时，外键应选用哪一个？

场景描述 #

我有user、user_role两张业务表，还有用于关联两者的多对多中间表user_has_user_role。为了遵循安全规范，不想对外暴露数据库的自增ID，因此在后端使用不可猜测的UUID7作为对外的二级ID（字段名id_be）。但数据库表的主键是自增ID，现在纠结外键应该关联自增ID还是id_be？

对应的数据库表结构SQL如下：

CREATE TABLE IF NOT EXISTS `user` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `id_be` BINARY(16) NOT NULL,
  `username` VARCHAR(45) NOT NULL,
  `password_hash` VARCHAR(255) NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `id_be_UNIQUE` (`id_be` ASC) VISIBLE,
  UNIQUE INDEX `username_UNIQUE` (`username` ASC) VISIBLE)
ENGINE = InnoDB

CREATE TABLE IF NOT EXISTS `user_role` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `id_be` BINARY(16) NOT NULL,
  `role` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB

CREATE TABLE IF NOT EXISTS `user_has_user_role` (
  `user_id` INT UNSIGNED NOT NULL,
  `user_role_id` INT UNSIGNED NOT NULL,
  PRIMARY KEY (`user_id`, `user_role_id`),
  INDEX `fk_user_has_user_role_user_role1_idx` (`user_role_id` ASC) VISIBLE,
  INDEX `fk_user_has_user_role_user_idx` (`user_id` ASC) VISIBLE,
  CONSTRAINT `fk_user_has_user_role_user`
    FOREIGN KEY (`user_id`)
    REFERENCES `progressive_coaches_db`.`user` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_user_has_user_role_user_role1`
    FOREIGN KEY (`user_role_id`)
    REFERENCES `progressive_coaches_db`.`user_role` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB

结论：外键用自增ID，id_be仅用于对外暴露 #

核心原因 #

• 性能优势明显：自增INT UNSIGNED仅占4字节，远小于BINARY(16)类型UUID的16字节。多对多关联表的复合主键如果用自增ID，总占用空间仅8字节；换成id_be的话需要32字节，索引存储开销直接翻4倍，JOIN查询的效率会显著下降，数据量大时更明显。
• 数据一致性更可靠：数据库主键是自增ID，外键直接关联主键符合关系型数据库的设计规范。主键的唯一性约束是数据库层面最严格的，避免了使用唯一索引字段（id_be）作为外键时的潜在风险——虽然UUID7重复概率极低，但自增ID绝对不会出现重复问题。
• 业务分层清晰：id_be的设计目的就是对外暴露时隐藏可猜测的自增ID，内部数据库用自增ID做关联完全不影响这个安全需求，内外层职责分离，架构逻辑更清晰。

不建议用id_be做外键的额外问题 #

• 关联表的复合索引体积过大，会导致查询时的IO开销增加，数据量越大性能下降越显著。
• InnoDB采用聚簇索引架构，自增ID的有序性更适配这种特性；而UUID是无序的，用它作为关联键会导致聚簇索引碎片增多，间接拖慢查询速度。

你的现有设计是合理的 #

当前user_has_user_role表用自增ID作为外键的设计完全符合最佳实践，无需调整。只需确保在对外接口返回数据时，只返回id_be字段，不暴露自增id即可。

内容的提问来源于stack exchange，提问作者stano561