主键冲突显示“for key 'primary'”，唯一键冲突显示“for key 'uk_phone'”等自定义名；主键强制非空且决定聚簇索引，唯一键允许null且为二级索引；添加时应显式命名以避免冲突和便于排查。
主键和唯一键都报 Duplicate entry 怎么区分？
看到 Duplicate entry 'xxx' for key 'PRIMARY' 就是主键冲突；如果是 Duplicate entry 'xxx' for key 'uk_phone'（或类似带名字的 key），那就是唯一键冲突。MySQL 在错误信息里明确写了哪个约束被触发，别猜——直接看 for key 后面的名字。
主键冲突通常意味着你试图插入重复的 id 或其他主键字段值；唯一键冲突则多发生在业务字段上，比如重复插入同一 phone 或 email。两者都会中断 INSERT，但修复方式不同：主键重复往往要检查自增逻辑或手动 ID 分配；唯一键重复得先查清是不是业务上真不该重复（比如用户注册时手机号已被占）。
NULL 值在唯一键里能插多次，主键里为什么不行？
MySQL 规定：主键字段 NOT NULL 是强制的，哪怕建表时没写，也会自动加上。所以只要字段设为主键，INSERT INTO t (id) VALUES (NULL) 必报 ERROR 1048: Column 'id' cannot be null。
而唯一键允许 NULL，且 MySQL 认为多个 NULL 不构成重复——这是 SQL 标准行为，不是 bug。所以你能连续执行：
INSERT INTO user (id, email) VALUES (1, NULL);<br>INSERT INTO user (id, email) VALUES (2, NULL);
只要 email 是 UNIQUE，这两条都成功。但第三条 INSERT INTO user (id, email) VALUES (3, 'a@b.com') 如果 'a@b.com' 已存在，就会触发唯一键冲突。
- 主键：不允许
NULL，强制唯一 + 非空 - 唯一键：允许
NULL，只保证非NULL值唯一
为什么用 phone 做唯一键，却不能替代主键？
因为主键不只是“唯一”，它还决定数据物理存储顺序（InnoDB 的聚簇索引）。主键值直接对应 B+ 树叶子节点里的整行数据；而唯一键是二级索引，叶子节点只存该字段值 + 主键值，查 name 这类非索引列时得回表一次。
这意味着：
- 用
phone当主键 → 查询手机号能直接拿到所有字段，快；但手机号变更成本高（要更新聚簇索引树），且业务上手机号可能变更或为空 - 用
phone当唯一键 → 插入/更新时校验不重复，查询仍走主键索引，变更灵活，但查手机号后取其他字段要额外回表
所以实际建模中，id（自增或 UUID）做主键，phone、email 单独加 UNIQUE，才是兼顾性能与语义的常见做法。
ALTER TABLE 添加唯一键时名字要不要指定？
要。MySQL 自动生成的唯一键名格式是 col_name，比如给 email 加唯一约束，不指定名字就叫 email；但如果表里已有同名字段或索引，会报错 ERROR 1061: Duplicate key name 'email'。
显式命名更安全：
ALTER TABLE user ADD UNIQUE KEY uk_email (email);
这样后续删约束也明确：ALTER TABLE user DROP INDEX uk_email;。别依赖 MySQL 自动生成名，尤其在多人协作或迁移脚本里，名字冲突是高频问题。
真正容易被忽略的是：唯一键名在错误提示、慢查询日志、SHOW CREATE TABLE 输出里都会出现，名字含糊会导致排查困难。比如看到 for key 'email'，你得翻半天 DDL 才确定是哪个字段；而 for key 'uk_email' 一眼可知。
