企业官网建设流程全解析

说实话，SQL Server 里这个“某字段为空时可以重复、不为空时必须唯一”的需求，我见过太多次了，但几乎每换一批同事就要重新讨论一遍。原因很简单：绝大多数人一开始会直接建一个 UNIQUE 约束，然后发现要么 NULL 的放行行为跟业务预期不一致，要么空字符串被拦截，要么想把已删除记录排除在外却完全无能为力。这篇文章我直接给你一条主线：先把“为空”的语义拆明白，再给出过滤唯一索引这个首选实现，最后把触发器和计算列这些备选方案放到桌上做对比，顺便把实际部署时容易掉进去的坑都指出来。

很多开发者的直觉是“SQL 里有 UNIQUE，那不就完事了？”但数据里的“空”其实分为 NULL 和空字符串''两种形态，SQL Server 对它们的态度完全不同。如果你连这层都没想清楚，后续建的索引大概率是错的。这篇内容适合正在做表设计、或者被存量数据“空值重复”折磨的人参考，老项目改造同样适用。

1. 先把“为空”这三个字拆清楚

1.1 NULL 和空字符串''到底差在哪

NULL 在关系数据库里表示“未知”，它不是一个值，而是“没有值”的标记。空字符串''则是一个确定的值，只不过这个值的内容为空。你可以这样理解：NULL 是“这栏没填，查不出来到底有没有填”，''是“这栏填了，填了一个空内容”。

这个差异直接决定唯一索引的行为。因为 NULL 不等于任何东西，甚至两个 NULL 互相之间也不相等，所以 SQL Server 认为两条 NULL 记录并不冲突。而 '' 就是''，两个空字符串必然相等，所以在普通唯一索引里绝对不允许共存。

你可以跑一段脚本快速验证这个区别：

CREATE TABLE #Demo ( Id INT IDENTITY PRIMARY KEY, Val VARCHAR(20) NULL ); CREATE UNIQUE INDEX UQ_Demo_Val ON #Demo(Val); -- 这条会成功 INSERT INTO #Demo(Val) VALUES (NULL); -- 这条也会成功，UNIQUE 索引允许多个 NULL INSERT INTO #Demo(Val) VALUES (NULL); -- 这条会成功 INSERT INTO #Demo(Val) VALUES (''); -- 这条会报“重复键”，因为两个 '' 被判定为重复 INSERT INTO #Demo(Val) VALUES (''); DROP TABLE #Demo;

你把这个结果记住：普通 UNIQUE 索引天然允许“多个 NULL 共存”，但不允许“多个空字符串共存”。所以如果业务里的“空”只表现为 NULL，普通唯一索引其实已经满足标题需求；一旦空值可能以''形态入库，就必须换方案。

1.2 哪些业务场景会踩中这个需求

这类约束最常见的场景是“部分记录参与唯一性校验”。我列几个实际遇到的：

这些场景有一个共同点：不是全表每一行都需要参与唯一性检查，只有满足某个状态的行才需要。普通 UNIQUE 索引做不到“只约束一部分行”，它要么全管，要么全不管。所以真正要解决的问题就变成了：如何让唯一性只作用于非空、有效的行。

1.3 先查清历史数据的“空”到底长什么样

动手建索引之前，建议先在目标表上跑一遍摸底查询，看看历史数据里的空值到底以什么形式存在。我给过一个很实用的脚本，你把表名和列名替换掉就能直接跑：

SELECT CASE WHEN TargetCol IS NULL THEN 'NULL' WHEN LTRIM(RTRIM(TargetCol)) = '' THEN 'EmptyString' WHEN LTRIM(RTRIM(TargetCol)) LIKE '% %' THEN 'ContainsSpace' ELSE 'NormalValue' END AS ValueType, COUNT(1) AS RowCount FROM dbo.YourTable GROUP BY CASE WHEN TargetCol IS NULL THEN 'NULL' WHEN LTRIM(RTRIM(TargetCol)) = '' THEN 'EmptyString' WHEN LTRIM(RTRIM(TargetCol)) LIKE '% %' THEN 'ContainsSpace' ELSE 'NormalValue' END;

从结果里你能一眼看出来：当前数据里有没有空字符串、有没有全空格、NULL 占比多少。这一步省掉之后 90% 的返工。

2. 首选方案：过滤唯一索引

2.1 原理一句话讲明白

过滤索引，又叫筛选索引，是 SQL Server 2008 开始引入的功能。它允许你在创建索引时加一个 WHERE 条件，索引里只存满足条件的行，不满足条件的行根本不进索引。

放在这个需求里，思路就非常清晰：给唯一索引加一个过滤条件“只看非空、非空字符串的行”。NULL 和'' 全部被排除在索引之外，它们自然不会参与唯一性校验，也就不存在重复冲突了。

你可以把它理解成一张会员名单：名单上只登记“有效且需要管”的人，没登记的人当然不会被查重。这是解决“部分行唯一”最优雅的手段，也是 SQL Server 官方推荐的做法。

2.2 建表和索引的完整脚本

假设有一张员工表，Email 列允许为空，但非空时必须唯一，而且业务里“空”同时包括 NULL 和''。脚本如下：

-- 如果表已存在，先清掉重新建，方便演示 IF OBJECT_ID('dbo.Employee', 'U') IS NOT NULL DROP TABLE dbo.Employee; CREATE TABLE dbo.Employee ( Id INT IDENTITY(1, 1) PRIMARY KEY, EmpName NVARCHAR(50) NOT NULL, Email NVARCHAR(100) NULL ); -- 核心索引：非空且非空字符串才唯一 CREATE UNIQUE INDEX UX_Employee_Email ON dbo.Employee(Email) WHERE Email IS NOT NULL AND Email <> '';

注意索引名字我用 UX_ 开头表示这是唯一约束性质的索引。这个过滤条件的意思是：只有当 Email 既不是 NULL、也不是空字符串时，这一行才进入索引并接受唯一性检查。

2.3 实测验证：四种数据都能按预期落地

接下来做插入测试，这段脚本模拟了真实操作场景：

-- 这四条都应该成功 INSERT INTO dbo.Employee(EmpName, Email) VALUES ('用户甲', NULL); INSERT INTO dbo.Employee(EmpName, Email) VALUES ('用户乙', NULL); INSERT INTO dbo.Employee(EmpName, Email) VALUES ('用户丙', ''); INSERT INTO dbo.Employee(EmpName, Email) VALUES ('用户丁', ''); -- 这个成功，首次使用 a@test.com INSERT INTO dbo.Employee(EmpName, Email) VALUES ('用户戊', 'a@test.com'); -- 这个必然报错，重复键冲突 -- INSERT INTO dbo.Employee(EmpName, Email) VALUES ('用户己', 'a@test.com');

执行结果应该是：前四条全部插入成功，最后一条如果取消注释，SQL Server 会报“不能在对象中插入重复键的行”错误。这个行为正好对应标题：为空时可以不唯一，不为空时必须唯一。

还有一点值得补充：如果你不需要把''视为“空”，过滤条件可以只写一个WHERE Email IS NOT NULL。但实际业务中 ORM 框架经常把用户没填的字段存成''而不是 NULL，所以我个人建议条件写得完整一点，宁可多排除一种情况也不要漏。

2.4 多列场景：组织内唯一、跨组织可重复

如果需求不是全局唯一，而是“同一个组织里不能重复，跨组织可以重复”，过滤索引同样能解决。假设一张用户表，LoginName 允许为空，但同一 OrgId 下的非空 LoginName 必须唯一：

CREATE UNIQUE INDEX UX_User_OrgLogin ON dbo.[User](OrgId, LoginName) WHERE OrgId IS NOT NULL AND LoginName IS NOT NULL AND LoginName <> '';

这样就保证不了“同一个 LoginName 在另一个组织重复”，因为唯一键是 (OrgId, LoginName) 的组合。

2.5 软删除场景：只对未删除记录做唯一

还有一种高频变体：软删除字段 IsDeleted = 0 表示有效记录，IsDeleted = 1 表示已删除。需求是“未删除的手机号唯一，已删除的手机号可以反复出现”。过滤索引写法如下：

CREATE UNIQUE INDEX UX_User_Phone_Active ON dbo.[User](Phone) WHERE IsDeleted = 0 AND Phone IS NOT NULL AND Phone <> '';

这个方案比应用层先 SELECT 再 INSERT 靠谱得多。应用层校验永远存在并发窗口：两个请求同时查到“不存在”，随后同时插入，数据库层没有约束就一定会出现重复。过滤唯一索引在数据库内部保证原子性，无论多少并发连接同时插入，最终只有一个能成功。

3. 备选方案对比：触发器、计算列为什么不优先

3.1 触发器也能实现，但要付代价

如果你用的 SQL Server 版本太老，或者业务规则极其复杂，过滤索引表达不了，那么触发器是唯一能兜底的方案。举个 AFTER 触发器的例子：

CREATE TRIGGER TR_Employee_Email_Unique ON dbo.Employee AFTER INSERT, UPDATE AS BEGIN SET NOCOUNT ON; IF EXISTS ( SELECT Email FROM dbo.Employee WHERE Email IS NOT NULL AND LTRIM(RTRIM(Email)) <> '' GROUP BY Email HAVING COUNT(1) > 1 ) BEGIN THROW 51000, 'Email 非空时必须唯一', 1; ROLLBACK TRANSACTION; RETURN; END END;

这个触发器在每次插入或更新后扫描整表，找出重复的非空 Email，然后抛错并回滚。逻辑看起来简单，但我强烈不建议把它当默认方案。原因有三个：

• 性能差。每次写操作都全表扫描，表越大越痛，高峰期能直接把业务拖垮。
• 并发不安全。两个会话同时插入同一个非空值，理论上都存在“先查不到重复，再插入”的窗口，需要自己加锁或用隔离级别做保护。
• 维护成本高。触发器的逻辑藏在数据库对象里，新来的同事排查问题时很容易忽略它，导致“明明没有唯一索引，却报唯一冲突”的困惑。

3.2 计算列方案：看起来很聪明，实际坑很多

我还见过有人用计算列绕弯子，思路是加一个“影子列”，把 NULL 转成每行不同的值，然后在这个影子列上建唯一索引：

ALTER TABLE dbo.Employee ADD EmailShadow AS ( CASE WHEN Email IS NOT NULL AND Email <> '' THEN Email ELSE CONVERT(VARCHAR(20), Id) END ) PERSISTED; CREATE UNIQUE INDEX UX_Employee_EmailShadow ON dbo.Employee(EmailShadow);

这个方案的问题非常明显：当 Email 为空时，影子列会取 Id，而 Id 每行必然不同，所以 NULL 和'' 都能重复存在。表面上达到了需求，但代价是索引里塞进了一堆毫无业务意义的“伪值”，索引体积变大，查询优化器还可能被误导。更关键的是，它绕了太多弯，后人维护时看到这个影子列根本不明白当初为什么这么设计。

还有一种更危险的做法，是把 NULL 统一转成''再建唯一索引：

-- 错误示范，千万别这么干 ALTER TABLE dbo.Employee ADD EmailBad AS (ISNULL(Email, '')) PERSISTED; CREATE UNIQUE INDEX UX_Employee_EmailBad ON dbo.Employee(EmailBad);

这样建出来的唯一索引会把所有 NULL 都变成同一个''，也就是所有未填写邮箱的人全部被判为重复，第一个 NULL 能插入，第二个 NULL 直接报错，完全背离需求。

3.3 四套方案横向对比

我把上述方案的特点整理成一张表，选型时看着它判断就行：

结论很清楚：能用过滤索引就优先用过滤索引，版本老到没有过滤索引再考虑触发器。计算列方案只适合“非空值本身类型与影子列类型匹配”的特殊场景，而且一定要在文档里写清楚，否则就是埋雷。

4. 实操中的高频问题和排查技巧

4.1 过滤索引不是所有查询都会自动命中

过滤索引有个特性很多人不理解：如果查询的 WHERE 条件与索引的过滤谓词不匹配，优化器可能不会选择这个索引。这其实是正常现象，但有一个禁忌你必须知道：不要在查询里强行使用索引提示。

比如你建了这样一条过滤索引：

CREATE UNIQUE INDEX UX_Employee_Email ON dbo.Employee(Email) WHERE Email IS NOT NULL AND Email <> '';

如果这时候写一条查询，强制用这个索引：

SELECT * FROM dbo.Employee WITH (INDEX = UX_Employee_Email) WHERE Email IS NULL;

结果是灾难性的。因为这个过滤索引里根本没有 NULL 行，强制使用它会导致查询结果漏掉所有 Email 为 NULL 的记录，而且 SQL Server 不会给你任何提示。所以我的建议是：过滤索引让优化器自行决定是否使用，除非你非常确定查询条件完全覆盖过滤谓词，否则永远不要对这个索引加 WITH (INDEX=...) 提示。

4.2 老版本 SQL Server 怎么办

如果项目还跑在 SQL Server 2005 上，没有过滤索引可用。这时候只能退而求其次：要么用触发器，要么改造数据模型。老项目改造时我见过一种做法是“软删除列 + 持久化计算列”组合，但前面已经分析过这个方案的问题，不推荐。另一个干净的做法是把“空值”统一规范化为 NULL，然后继续用普通 UNIQUE 索引，但这需要业务层配合，ORM 映射里明确指定空字符串转 NULL。从长期维护角度看，升级数据库版本到 2008 以上才是治本方案。

4.3 历史脏数据会导致索引创建失败

这是最典型的翻车场景：表里已经存在两条相同的非空 Email，你再想加过滤唯一索引，SQL Server 会告诉你创建失败，因为数据本身不满足唯一性。遇到这种情况，先把重复数据查出来：

SELECT Email, COUNT(1) AS DuplicateCount FROM dbo.Employee WHERE Email IS NOT NULL AND Email <> '' GROUP BY Email HAVING COUNT(1) > 1;

然后根据业务决定怎么处理：给重复值追加后缀、合并账号、或者直接把无效数据标记为已删除。清理干净后再创建索引，否则索引永远建不上。

4.4 命名规范和统计信息

过滤索引建议在命名里带一个标志，方便运维识别。比如：

• UX_ 表示唯一性约束
• F_ 或 FLT_ 表示过滤索引
• 后面跟表名和列名

我习惯的写法是 UX_Employee_Email_Flt，或者服务端规范要求更严的话写成 IX_Unique_F_Employee_Email。命名清晰能省很多排查时间。

另外，过滤索引会生成独立的统计信息对象，统计范围只包含过滤进来的行。这个特性对查询优化其实是好处：优化器对“非空值分布”的判断比全表统计更精准，相关查询的执行计划质量往往更高。代价是索引维护期间读写成本略增，但相比它解决的问题，这点代价完全可以接受。

4.5 常见问题速查表

5. 一个老项目改造的完整落地过程

我拿一个真实案例来讲：某公司内部系统，员工表已经有大量数据，Email 列原本用普通 UNIQUE 索引，导致很多没填邮箱的员工被空字符串锁住，系统里只能有一条 '' 记录，用户填了邮箱之后又无法重复录入，运维天天手工清理。

改造步骤如下：

第一步，备份全库，尤其是目标表。任何加索引操作都可能因为历史数据问题失败，备份是底线。

第二步，跑摸底查询，确认空值形态。结果发现库里同时存在 NULL 和 '' 两种形态，还有几条带空格的脏数据。

第三步，清洗历史数据。把 '' 和全空格统一转成 NULL，执行更新前先查影响行数：

UPDATE dbo.Employee SET Email = NULL WHERE LTRIM(RTRIM(ISNULL(Email, ''))) = '';

第四步，删除旧的普通唯一索引：

DROP INDEX UQ_Employee_Email ON dbo.Employee;

第五步，创建过滤唯一索引：

CREATE UNIQUE INDEX UX_Employee_Email_Flt ON dbo.Employee(Email) WHERE Email IS NOT NULL AND Email <> '';

第六步，做回归验证。用一批真实数据走一遍插入流程，确认 NULL、'' 可以重复出现，非空值重复会被拦截。

第七步，观察一段时间。重点监控死锁和阻塞，因为过滤索引可能影响此前依赖旧索引的查询计划。如果某个高频查询性能下降，对比执行计划再做调整。

这个流程走下来，总共不到半天时间，系统里再也没有出现过“空值抢唯一名额”的工单。

最后再分享一个经验：我接手这类需求时，第一件事永远不是写 SQL，而是去查历史数据的“空”到底长什么样。很多开发想当然以为 NULL 和空字符串一样，结果建完过滤索引才发现漏了空串的判断。先用 GROUP BY 把 NULL、''、全空格都捞出来看一眼，再决定过滤条件和要不要做数据清洗。磨刀不误砍柴工，这一步能帮你省下后面所有返工的时间。