mysql添加唯一约束最常踩的坑是语法顺序和字段括号位置，正确写法必须显式命名约束且字段列表紧贴unique key后：alter table users add unique key uk_email (email);
ALTER TABLE ADD UNIQUE KEY 语法写不对会报错
MySQL 添加唯一约束最常踩的坑是语法顺序和字段括号位置。不是 ADD UNIQUE KEY (col)，也不是 ADD UNIQUE (col)，正确写法必须带约束名（推荐显式命名），且字段列表在括号里紧贴 UNIQUE KEY 后面：
-
ALTER TABLE users ADD UNIQUE KEY uk_email (email);✅ 显式命名 + 字段在括号内 -
ALTER TABLE users ADD UNIQUE (email);⚠️ 虽然能执行，但 MySQL 自动命名（如users_email_uk），后续删约束时得查SHOW CREATE TABLE才知道名字 -
ALTER TABLE users ADD UNIQUE KEY email (email);❌ 如果email已是列名，这里会被误认为是约束名，但列名和约束名同名不报错却难维护 -
ALTER TABLE users ADD UNIQUE KEY (email);❌ 缺少约束名，MySQL 5.7+ 会报ERROR 1064
已有重复数据时 ADD UNIQUE KEY 会直接失败
唯一约束本质是建索引，而索引要求字段值全局唯一。只要表里存在两行 email 都是 test@example.com，命令就会中断并提示：
ERROR 1062 (23000): Duplicate entry 'test@example.com' for key 'uk_email'
- 先用
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;找出重复项 - 根据业务决定：删多余行、合并记录，或加条件过滤（比如只对
status = 'active'建唯一约束——但注意，这得用函数索引或生成列，普通UNIQUE KEY不支持 WHERE） - 别指望加
IGNORE（ALTER IGNORE TABLE ...）——该语法在 MySQL 5.7.4+ 已被移除，强行用会报错
NULL 值在 UNIQUE 约束下不算重复，但有陷阱
MySQL 的 UNIQUE KEY 允许任意数量的 NULL，这是标准行为，但容易误判：
- 如果
email列允许NULL，那么插入 10 行email = NULL不会触发唯一冲突 - 但如果你本意是“每个用户必须有邮箱且不能重复”，就得额外加
NOT NULL：ALTER TABLE users MODIFY email VARCHAR(255) NOT NULL;，再加唯一约束 - 联合唯一约束也一样：
ADD UNIQUE KEY uk_user_role (user_id, role)中，只要任一字段为NULL，整行就不参与去重判断
删除或禁用唯一约束不能靠 DROP INDEX 混用
很多人以为 UNIQUE KEY 就是唯一索引，所以想用 DROP INDEX uk_email ON users 删除——这在大多数情况下可行，但有例外：
- 如果该约束是主键（
PRIMARY KEY），或者由CREATE TABLE时隐式创建（比如email VARCHAR(255) UNIQUE），那它没有独立约束名，DROP INDEX可能失败或误删其他索引 - 安全做法永远是查清楚：
SHOW CREATE TABLE users;看约束名，然后用DROP INDEX uk_email ON users;或更规范的ALTER TABLE users DROP INDEX uk_email; - 没有“禁用唯一约束”这回事——MySQL 不支持
DISABLE KEY，要临时绕过只能删掉再重建，或者改应用逻辑
真正麻烦的是跨环境同步：开发库手动加了约束，但没写进迁移脚本，上线时就漏了；或者约束名在不同版本 MySQL 中生成规则不同，导致自动化部署失败。
