SQL 唯一索引 vs 普通索引 vs 唯一约束的业务唯一性保障选择

有区别，但仅在语义和维护习惯上，底层均依赖唯一索引实现；唯一约束提升元数据可读性与 orm 兼容性，而唯一索引支持前缀、算法等高级配置。

唯一索引和唯一约束在业务上到底有没有区别？

有区别，但只在语义层和维护习惯上——底层都依赖唯一索引实现。MySQL 里 ALTER TABLE t ADD CONSTRAINT uk_email UNIQUE(email) 和 CREATE UNIQUE INDEX uk_email ON t(email) 最终生成的索引结构、查询行为、冲突报错（1062 Duplicate entry）完全一致。

真正影响业务的是：唯一约束自带命名规范和元数据可读性，DBA 或 ORM 迁移时更容易识别“这是业务规则”；而裸建的唯一索引容易被当成纯性能优化手段，后期被误删或忽略。

• PostgreSQL 会为唯一约束自动创建同名唯一索引，删除约束即删索引；MySQL 8.0+ 同理
• 如果用 SHOW CREATE TABLE 查看，约束写法会在 CONSTRAINT 行显式声明，索引写法则只出现在 KEY 行，对自动化校验工具更友好
• 某些 ORM（如 Django）对 unique=True 字段默认映射为唯一约束，而非索引；手动建索引可能绕过框架的完整性检查逻辑

普通索引能防重复插入吗？

不能。普通索引（INDEX）只加速查询，不校验唯一性。哪怕你在 email 字段建了普通索引，执行 INSERT INTO t(email) VALUES ('a@b.com'), ('a@b.com') 依然成功，表里会出现两条重复记录。

常见误判场景：看到慢查询日志里某字段加了索引，就以为“应该不会重复”，结果下游业务因脏数据出错。唯一性必须由数据库强制保证，不能靠应用层“自觉”或索引“顺带”。

• 唯一性校验发生在 INSERT/UPDATE 的写入路径末尾，普通索引不参与该检查
• 如果你只想要去重效果（比如 ETL 场景），得用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，但这依赖已有唯一索引 / 约束存在
• 没有唯一索引时，靠 SELECT + INSERT 判断是竞态高发区，别用

什么时候该用唯一索引而不是唯一约束？

两种情况：一是需要多列组合唯一但不想暴露约束名（比如临时清洗表），二是要指定索引类型或参数——唯一约束不支持这些。

例如想建前缀唯一索引（MySQL 中 VARCHAR(255) 字段太长，全字段索引开销大），只能用唯一索引语法：

CREATE UNIQUE INDEX uk_user_name_prefix ON users(name(10));

再比如想用 BTREE 以外的引擎（虽然少见），或者指定 KEY_BLOCK_SIZE、COMMENT 等索引级配置，唯一约束语法不支持。

• 唯一约束无法指定索引算法（USING BTREE / USING HASH），而唯一索引可以
• 约束名在错误信息里直接出现（ER_DUP_ENTRY: Duplicate entry 'xxx' for key 'uk_email'），索引名也一样，所以可读性差异不大
• 如果字段本身是主键或已有主键，再加唯一约束会多一层冗余元数据，此时直接建唯一索引更轻量

唯一性保障失效的三个隐蔽坑

即使建了唯一索引或约束，业务仍可能漏掉重复——问题通常不出在 DDL，而出在数据本身或 SQL 写法。

• NULL 值不参与唯一校验：MySQL 中，UNIQUE(email) 允许多个 NULL，因为 NULL != NULL。如果业务把空邮箱记为 NULL，就会积累大量“逻辑重复”
• 字符集与排序规则（collation）影响比较：比如 utf8mb4_0900_as_cs 区分大小写，而 utf8mb4_unicode_ci 不区分。同一个邮箱 A@B.COM 和 a@b.com 在后者下会被视为重复，前者则不会
• 表达式索引或函数索引未覆盖业务逻辑：比如业务要求“邮箱小写后唯一”，但只在原始字段建了唯一索引。正确做法是建函数索引：CREATE UNIQUE INDEX uk_email_lower ON users((LOWER(email)))（MySQL 8.0.13+）

这些点不会报错，也不会阻断部署，但会让唯一性形同虚设——查的时候发现数据早就不干净了。