MySQL唯一约束为何允许NULL重复插入

关于 MySQL 中 UNIQUE 约束无法禁止 NULL 值重复插入的问题，不少开发者在实际使用中都会感到困惑：明明是唯一约束，为什么允许插入多个 NULL？原因其实并不复杂，这是 SQL 标准规定的行为——NULL 在数据库中被视为“未知值”，而非具体值，因此两个未知数之间无法比较，`NULL = NULL` 的结果是 `NULL` 而不是 `TRUE`。正因如此，MySQL 在执行 UNIQUE 索引时，对非 NULL 值会严格进行重复校验，但遇到 NULL 时，直接跳过冲突判断，导致多个 NULL 可以共存。

那么，这个“设计特性”会在哪些场景埋下隐患？实践中常见的踩坑场景包括：

• 用户表的 `email` 字段允许为空，但无意中插入了 10 条 `email = NULL` 的记录，本以为 UNIQUE 约束能防止重复，结果查重逻辑完全失效，数据层面出现明显错误。
• 商品表使用 `(category_id, model_hash)` 建立联合唯一索引，本意是防止同一规格的商品重复上架，但 `model_hash` 字段可为空，导致同一分类下可以插入多条“无属性”商品，业务逻辑陷入混乱。
• 更隐蔽的问题：旧数据迁移时已包含若干 NULL 记录，后续想为字段添加 UNIQUE 约束，要么直接失败报错，要么约束添加后并不生效，白白浪费排查时间。

既然 UNIQUE 本身无法解决 NULL 重复问题，如何真正禁止 NULL 重复？以下几种方案可供选择：

一、添加 `NOT NULL` 约束，这是最直接的方式。 先执行 `ALTER TABLE users MODIFY email VARCHAR(255) NOT NULL` 将字段设为非空，再添加 `ADD UNIQUE(email)` 唯一约束，从数据层面一次性补齐短板。

二、使用生成列加唯一索引。 例如 `ALTER TABLE users ADD COLUMN email_notnull VARCHAR(255) AS (COALESCE(email, CONCAT('null_', id))) STORED`，然后对 `email_notnull` 建立 UNIQUE 索引。这样 NULL 会被转化为一个具体的“替代值”，从而参与约束判断。

三、在业务层自行兜底。 插入前先执行 `SELECT COUNT(*) FROM users WHERE email IS NULL`，若结果大于 0 则拒绝插入。但需注意并发竞争——多个请求同时在检查后插入，仍可能出现数据异常。

四、使用触发器拦截（谨慎使用）。 在 `BEFORE INSERT` 触发器中判断 `NEW.email IS NULL` 并计数，若存在 NULL 值则回滚操作。缺点明显：性能差、维护困难，不建议作为首选方案。

另外，删除 UNIQUE 约束时也需要警惕，避免误用 `DROP INDEX` 踩坑。不少人直接写 `DROP INDEX uk_email ON users`，但风险相当大：

• 如果约束是通过 `email VARCHAR(255) UNIQUE` 这种隐式方式创建的，它并没有显式索引名，直接使用 `DROP INDEX` 只会报错。
• 如果是主键衍生的 UNIQUE（例如 `PRIMARY KEY` 自带的唯一性），贸然执行 `DROP INDEX` 可能误删主键索引，导致表结构混乱。
• 正确的做法是先用以下语句查询约束名：
  SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'users' AND COLUMN_NAME = 'email';
  再使用 `ALTER TABLE users DROP INDEX uk_email;` 安全删除。

归根结底，UNIQUE 约束对 NULL 的宽容是设计使然，并非 Bug。但如果将其视为“全量去重”的万能方案，必然导致数据遗漏。关键在于理解字段语义：如果 NULL 表示“未提供”或“未知”，它应当被视为一种有效状态，并纳入去重逻辑的考量。依赖索引的默认行为来掩盖逻辑缺陷，终究不是长久之计。