唯一索引确保索引键值不重复，从而实现行级唯一性；外键仅保证引用存在，不阻止多行指向同一主键，故一对一必须额外创建唯一索引（如CREATE UNIQUE INDEX IX_profile_user_id ON profile(user_id)）来强制“最多一个”约束。
在 SQL Server 中，仅靠外键无法实现真正的一对一关系；必须在关联字段（通常是外键列）上显式创建唯一索引，否则允许重复外键值，变成一对多。
为什么外键本身不等于一对一约束
外键只保证引用存在，不阻止多个子记录指向同一个父主键。比如 user_id 在 profile 表中设为外键指向 users.id，但没加唯一性限制时，可以插入多条 user_id = 5 的记录——这是一对多，不是一对一。
常见错误现象：INSERT 成功但业务逻辑崩了，查出多个 profile 对应一个 user，前端报“用户资料冲突”却查不到数据库层面的报错。
- 外键是“存在性检查”，不是“数量控制”
- 一对一本质是“最多一个”，需靠唯一性机制强制执行
- SQL Server 不提供
ONE TO ONE关键字，全靠组合约束实现
在关联字段上创建唯一索引的两种写法
推荐直接用 CREATE UNIQUE INDEX，语义清晰、可命名、易排查。避免依赖 UI 工具隐式创建（如 SSMS 勾选“忽略重复键”，反而埋下隐患）。
正确示例：
CREATE UNIQUE INDEX IX_profile_user_id ON profile (user_id);
等价但更紧凑的写法（通过约束语法）：
ALTER TABLE profile ADD CONSTRAINT UQ_profile_user_id UNIQUE (user_id);
两者在查询优化器眼中无区别，但注意：
-
UQ_前缀是惯例，方便识别这是唯一约束而非主键 - 如果
user_id允许 NULL，SQL Server 会把所有 NULL 视为相同值，导致无法插入第二行 NULL —— 这通常不是你想要的，建议设为NOT NULL - 若已有重复数据，
CREATE UNIQUE INDEX会直接报错（消息 1505），必须先清理
NULL 值如何影响唯一索引的实际行为
SQL Server 把多个 NULL 当作重复值处理。这意味着：如果 user_id 是可空的，且你已有一行 user_id IS NULL，再插一行同样为 NULL 就会触发唯一冲突（错误 2627）。
这不是 bug，是标准行为。所以实际建模时要明确策略：
- 若业务允许“无关联 profile”，用单独状态字段（如
is_active）代替 NULL 外键 - 若必须保留 NULL，考虑用过滤索引避开：
CREATE UNIQUE INDEX IX_profile_user_id_nonnull ON profile (user_id) WHERE user_id IS NOT NULL; - 不要指望“NULL 不参与唯一判断”——SQL Server 没这个选项
与主键或替代键混用时的注意事项
如果 profile 表本身以 user_id 为主键，那它天然具备唯一性，无需额外索引。但要注意：主键 ≠ 外键指向目标，只是碰巧值相同。
更常见的陷阱是复合唯一场景，例如“每个用户最多一个紧急联系人，但按类型区分”：
CREATE UNIQUE INDEX IX_contact_user_type ON contact (user_id, contact_type);
这时单列 user_id 不需要唯一，但组合必须唯一。别误删掉这个复合索引只留单列——约束就失效了。
复杂点在于：唯一索引一旦涉及多列或条件过滤，排查冲突时得看执行计划里的 Seek Predicate 是否命中该索引，而不是只扫表结构。
