为什么MySQL的Unique唯一约束不能阻止Null值的重复插入？

UNIQUE约束放行多个NULL因SQL标准将NULL视为未知值，NULL= NULL不成立，故数据库仅对非NULL值校验唯一性；这导致email或model_hash为NULL时重复插入、查重失效等问题，需用NOT NULL、生成列或业务层兜底解决。

UNIQUE约束为什么放行多个NULL

因为SQL标准规定NULL是“未知值”，不是具体值，NULL = NULL 返回的是NULL（非TRUE），所以数据库不认为两个NULL相等。MySQL的UNIQUE索引只对非NULL值做去重校验，只要字段值不是确定的，就跳过冲突判断。

哪些场景下这会出问题

业务上常误以为“唯一”=“不能重复”，但实际它只拦住确定值的重复。典型踩坑点：

• 用户表的email字段允许NULL，结果插入10条email = NULL记录，查重逻辑失效
• 商品表用(category_id, model_hash)建联合唯一索引，但model_hash可为空，导致同一分类下多个“无属性”的商品被重复创建
• 迁移旧数据时已有NULL，后续加UNIQUE失败，或加了却没生效，误以为约束已起作用

怎么真正禁止NULL重复

靠UNIQUE本身做不到，必须组合其他手段：

• 加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
• 业务层兜底：插入前查SELECT COUNT(*) FROM users WHERE email IS NULL，大于0就拒绝（注意并发竞争）
• 触发器拦截（慎用）：在BEFORE INSERT里判NEW.email IS 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代表“未提供”，那它本身就该被当作一种有效状态参与去重，而不是靠索引默认行为来掩盖逻辑缺陷。