SQL唯一约束的核心目标是保证数据不重复，本质是自动创建唯一索引，影响写入性能与查询效率；需谨慎选择字段、考虑复合索引顺序、避免长文本或UUID直接建约束，优先用哈希+应用校验；业务语义（如有效状态、大小写处理、软删除）比技术强制更重要，须结合条件索引、触发器或应用层控制，并持续监控执行计划与冲突频次。
SQL唯一约束的核心目标是保证数据不重复，但它对查询性能的影响常被低估。设计时不能只看“加个UNIQUE就行”，而要结合字段选择、索引机制和业务场景综合判断。
唯一约束本质是唯一索引
在主流数据库（MySQL、PostgreSQL、SQL Server）中，定义唯一约束会自动创建对应唯一索引。这意味着：
- 插入/更新操作需额外校验索引，高并发写入时可能成为瓶颈
- 查询中若用到该列做等值查找（如 WHERE user_email = 'a@b.com'），可走索引加速
- 复合唯一约束（如 (user_id, role_type)）的索引顺序影响范围查询效率，前导列必须参与才能有效利用
慎用长文本或高基数字段建唯一约束
对TEXT、JSON或超长VARCHAR字段加唯一约束，会导致索引体积膨胀、维护开销上升：
- MySQL中BLOB/TEXT列不能直接建唯一索引，需指定前缀长度（如 email(191)），但可能引发哈希冲突误判
- UUID类字符串虽天然唯一，但随机写入易造成B+树页分裂，降低插入吞吐
- 推荐方案：对原始字段计算确定性哈希（如 SHA256），在哈希值上建唯一索引，再配合应用层校验原始值
业务语义比技术强制更重要
唯一性需求常隐含业务规则，而非单纯字段去重：
- “手机号唯一”通常指“当前有效用户中唯一”，需排除已注销账号，这时应加状态条件索引（如 PostgreSQL 的部分索引 CREATE UNIQUE INDEX idx_active_phone ON users(phone) WHERE status = 'active'）
- “用户名不重复”可能允许大小写不同（'Alice' 和 'alice' 视为同一人），此时需统一转小写存储 + 唯一索引，而非依赖 COLLATE
- 软删除场景下，直接加唯一约束会导致历史记录干扰新数据，应改用触发器或应用层控制
监控与演进比一次性设计更关键
唯一约束上线后需持续观察实际效果：
- 检查执行计划，确认高频查询是否真实命中唯一索引（注意索引失效场景：隐式类型转换、函数包裹字段等）
- 统计唯一键冲突频次，高频冲突往往暴露业务流程缺陷（如注册重试未幂等）
- 当表数据量超千万且写入压力大时，考虑将唯一校验下沉到应用缓存（如 Redis SETNX）或分库分表路由层，减轻数据库负担
不复杂但容易忽略。
