有区别，但仅在语义和维护习惯上，底层均依赖唯一索引实现；唯一约束提升元数据可读性与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+）
这些点不会报错，也不会阻断部署，但会让唯一性形同虚设——查的时候发现数据早就不干净了。
