主键确保行唯一性并提升查询性能，外键维护表间引用完整性；真实项目中应优先用BIGINT自增主键，开发环境启用外键约束以暴露逻辑缺陷，生产环境则移除外键改由应用层保障一致性，同时必须为外键字段单独建索引以防全表扫描。
真实项目中主键外键的设计直接影响数据一致性、查询性能和后续扩展能力，不是照着ER图随便加个ID和FOREIGN KEY就能上线的——比如订单表用字符串UUID作主键，却没建对应索引，高峰期JOIN用户表直接拖垮数据库。
主键选型：优先数字自增，除非有明确分布式需求
第一步：新建表时默认使用 BIGINT UNSIGNED AUTO_INCREMENT 作为主键字段，命名为 id。
这一步操作起来很简单，直接在建表语句里写 id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY 即可。MySQL 8.0+ 对自增主键的并发插入优化已很成熟，吞吐量足够支撑日单量百万级业务。
第二步：若业务确需全局唯一且跨库生成（如分库分表+多机房部署），才考虑雪花算法生成的 LONG 型 ID，【必须确保机器ID和数据中心ID配置正确，否则会出现重复】；绝对不用 UUID 或 UUID_SHORT() 作主键——它们无序写入导致聚簇索引频繁页分裂，SSD寿命都会缩短。
第三步：禁止用业务字段（如手机号、身份证号）当主键。这些字段可能变更、存在隐私合规风险，且长度大、比较慢，还会让所有二级索引变胖。
外键约束：开发环境开，生产环境关
方法一：开发阶段开启外键检查，建表时显式声明 FOREIGN KEY，并配上 ON DELETE CASCADE 或 ON UPDATE RESTRICT。
这能立刻暴露逻辑漏洞——比如删除用户时没处理关联订单，执行 DROP USER 就会报错，逼你补上清理逻辑。
方法二：上线前统一去掉外键定义，改用应用层校验+事务兜底。MySQL 在高并发下外键会持有元数据锁（MDL），曾有项目因一个外键导致 ALTER TABLE 被阻塞 47 分钟。
【删外键前务必确认所有 DELETE/UPDATE 操作都已覆盖关联清理路径，漏一条就会产生脏数据】
联合外键与冗余字段的取舍
当一张表需要同时指向两个父表（如“课程报名记录”既要关联“学生”，又要关联“班级”），优先建两个独立外键字段 student_id 和 class_id，各自配索引。
不要为了“范式洁癖”强行搞联合外键 (student_id, class_id)，因为绝大多数查询只按 student_id 查，联合索引最左前缀失效；更不要只存 class_id + 冗余 student_name 字段——名字会改，改一次就得全表UPDATE，还破坏原子性。
这一步的关键是看查询模式：90% 的 WHERE 条件只含其中一个字段，就拆开建；真有高频双字段等值查询（如 WHERE student_id=123 AND class_id=456），再补一个联合索引。
索引配套：外键字段不加索引等于埋雷
只要定义了外键，立刻给该字段单独建 B+ 树索引。
MySQL 不会自动为外键字段建索引，但每次 DELETE 父记录时，都要扫描子表验证约束，没索引就是全表扫——一个 2000 万行的订单表，删一个用户卡住 3 秒，DBA 就会冲进你工位。
如果该字段已是联合索引的非首列（比如已有 index(status, user_id)），必须额外补一个 index(user_id) 单独索引，否则外键校验仍走不了索引。
