SQL Server约束与数据库管理：原理、实操与避坑指南

2026年1月21日我把一整天的时间都用在了“SQL Server约束与数据库管理”这个专题上。说直白一点这个标题拆开看就是两件事一是把主键、外键、唯一、CHECK、默认值这些约束从原理到实践彻底弄明白二是约束真正落地之后数据库日常管理里那些保证数据完整性、稳定性的动作该怎么编排。这篇复盘笔记既是我的阶段性沉淀也是给正在做表结构设计、或者深陷老库脏数据泥潭的人的一份实操参考。我为什么把约束和数据库管理放在一起讲因为这两件事本质上是一体的。约束的相关操作不是建表那一刻“用一下”就结束的它后续的维护、排查、恢复、优化恰恰属于数据库管理的核心范畴。我也见过不少项目应用层校验写得很热闹数据库层却几乎没有约束外键完全靠代码逻辑撑着主键直接用业务号CHECK一个都没建。结果就是多个系统同步数据时脏数据直接穿透到核心表并发写入时两个请求同时插入相同业务编号应用层“先查后插”的做法必然出现竞争窗口。数据库约束的价值恰恰在于它是最后一道闸门——不管数据来源是Web接口、数据导入、运维脚本还是人工修补只要违反规则引擎就拒绝落库。这种底层层面的强硬约束是应用代码给不了的。这篇文章我会按实战顺序来讲先拆解约束体系的原理和适用场景然后给出建表、改表、查元数据的完整操作路径接着聊聊约束上线后数据库日常管理的核心动作最后把我在实践里踩过的和帮别人排查过的典型问题整理成避坑手册。内容全程围绕SQL Server展开但不少思路放到其他关系型数据库同样适用。适合SQL Server初中级开发者、要接手数据库维护的后端工程师以及被数据质量问题反复折磨的临时DBA。1. 约束到底是什么六类约束的原理与应用场景拆解1.1 一个真实场景看清约束的价值假设一个订单系统核心就是两张表用户表Users和订单表Orders。业务规则大概有这么几条用户名不能重复年龄必须落在0到120之间订单必须关联一个有效用户订单金额不能为负数。如果没有数据库约束这些规则就只能在应用层各自校验。问题在于数据入口往往不止一个管理后台有录入界面用户自己会注册和下单ESB同步会往库里面灌数据运维脚本也会做批量订正。只要有一个入口漏掉了校验坏数据就进库了。更麻烦的是并发场景两个请求同时插入相同用户名的记录应用层“先查后插”的写法几乎必然出现竞争空隙最终收到PK冲突或唯一约束报错的人还是开发自己。约束的思维方式是“声明式”的。你告诉数据库规则是什么违反规则的操作在提交时就会被引擎拒绝从根上消除了入口不一致和并发竞争的问题。这就是我一直强调的约束不是在限制业务而是在帮业务把“默认正确”的数据写进磁盘。等数据量大起来、入口多起来你会感谢这些提前设好的闸门。1.2 六类约束逐个拆解主键、外键、唯一、CHECK、默认值、非空先把最常用的一张速查表放在前面后面每个类型我再单独讲透约束类型核心作用一个表能建几个是否自动建索引关键注意事项主键约束 PRIMARY KEY唯一标识一行实现实体完整性1个可复合是默认建聚集索引不允许NULL复合主键会加大索引体积外键约束 FOREIGN KEY引用另一表的主键或唯一列保证引用完整性多个否强烈建议手动建外键列无索引容易引发锁与性能问题唯一约束 UNIQUE保证列或组合值不重复多个是建唯一索引SQL Server中默认允许多个NULL注意业务语义检查约束 CHECK保证列满足逻辑表达式多个否遇到NULL会返回UNKNOWN不会阻止NULL行默认值约束 DEFAULT插入语句未指定列值时自动填充多个否不作用于已有数据只影响后续INSERT非空约束 NOT NULL禁止NULL写入多个按列否它是列属性不是独立对象约束主键约束的核心问题是选型。用自增ID做主键简单高效但不少团队喜欢拿业务编号直接做键比如订单号加商品号的复合主键。复合主键不是不能用而是后续所有外键引用都要带着全部列索引体积、关联复杂度都会成倍上升而且上线后几乎没法改。我的建议是优先代理主键自增列或GUID都行业务唯一性单独用唯一约束去保障。这是数据库设计里代价最低、扩展性最好的主键方案。外键约束有一个非常容易被忽略的点SQL Server默认情况下不会自动为外键列创建索引。这意味着当父表删除一条记录、需要检查子表是否存在引用时如果没有索引引擎会对子表的外键列做全表扫描。我见过的一套业务系统每天删除父表上万条记录因为子表外键没索引每次删除都在全表扫几分钟内整个库就被锁到几乎不可用。解决方案不复杂在外键列上补一个非聚集索引删除成本会从全表扫描降为索引查找量级完全不一样。唯一约束和主键经常被弄混。区别在于主键侧重“身份标识”一个表一般只应该有一个唯一约束侧重“业务值不重复”可以有多个。比如用户表用UserId做主键同时Email列和Mobile列都需要唯一约束这就是典型的“一个主键多个唯一”结构。这里要特别强调SQL Server的一个特性唯一约束默认允许多个NULL这一点和Oracle很不一样。换句话说如果你希望“邮箱要么为空、要么全局不重复”那唯一约束能办到但如果你还希望“空值也只能有一条”就需要额外的方案后面第4章我会给出具体做法。CHECK约束是很多人用得最少、其实最实用的一类。它不只是限制数值范围还可以用LIKE做简单格式校验用IN做枚举白名单甚至可以组合多列做业务判断比如“状态为已发货时必须填写物流单号”这种跨列规则。CHECK的表达式本质上就是布尔逻辑结果为TRUE就通过。但这里藏着一个SQL三值逻辑的坑当表达式涉及的列是NULL时整个表达式的结果是UNKNOWN而不是FALSESQL Server对UNKNOWN的处理是放行因为它只拒绝结果为FALSE的行。所以如果你写CHECK (Age 18)Age为NULL的行照样能插进去。这个点我第4章会重点展开。默认值约束的核心认知是它只管INSERT和UPDATE、和已有数据都没有关系。加上DEFAULT之后如果INSERT语句没指定该列引擎会用默认值如果INSERT语句明确写了NULL只要列允许NULL最终写入的就是NULL不会自动替换成默认值。很多新手以为“设置DEFAULT后插入NULL会变成默认值”这是误解。要让列彻底避免NULL进入需要DEFAULT和NOT NULL配合使用。最后是非空约束NOT NULL。它看着最简单却是整个约束体系的地基。一个列一旦允许NULL后续的CHECK、唯一性、默认值设计全都会受影响。我设计表时的黄金法则是能非空就非空除非业务上明确允许缺失。NULL在计算、索引、查询条件、外键关联里带来的麻烦远比建表时多写几个NOT NULL要多得多。1.3 约束与索引之间那些默认行为刚才的速查表里已经体现了主键和唯一约束会自动创建索引外键不会。这里的逻辑很清晰主键和唯一约束为了判断“值是否重复”引索引是天然工具外键只是为了“查有没有引用”它本身不要求唯一所以引擎不会自动建。但正是这个“不自动”让很多表在引用完整性上埋下了严重的性能隐患。还有一个值得注意的点主键默认创建的是聚集索引但这不等于主键必须是聚集索引。你可以显式把主键指定为NONCLUSTERED然后让聚集索引落在更贴合查询模式的列上。比如订单流水表主键是自增的OrderId但业务经常按UserId和时间范围查订单这时候主键用非聚集索引另外在UserIdOrderDate上建聚集索引性能会更贴合实际场景。不过这是设计层面的取舍不是所有表都适合不要为了炫技乱用。最后提一个概念约束本身可能被“禁用”也可能处于“不可信”状态。SQL Server允许对外键和CHECK约束执行NOCHECK让它们暂时失效也允许通过WITH NOCHECK添加约束时跳过对旧数据的验证。禁用和不可信都会让约束的实际价值大打折扣而判断这些状态、把它们恢复到正常状态恰恰是数据库管理的关键战场我会在第3章详细讲。2. 从建表到上线约束设计与变更的完整实操2.1 建表时直接定义约束的标准写法直接上脚本。这是我这次复盘用来做演示的业务模型一个用户表外加一个订单表基本覆盖了最常用的约束类型CREATE TABLE dbo.Users ( UserId INT IDENTITY(1,1) NOT NULL, UserName NVARCHAR(50) NOT NULL, Email NVARCHAR(100) NULL, Age TINYINT NULL, Status TINYINT NOT NULL CONSTRAINT DF_Users_Status DEFAULT (1), CreatedAt DATETIME2 NOT NULL CONSTRAINT DF_Users_CreatedAt DEFAULT (SYSDATETIME()), CONSTRAINT PK_Users PRIMARY KEY CLUSTERED (UserId), CONSTRAINT UQ_Users_UserName UNIQUE (UserName), CONSTRAINT CK_Users_Age CHECK (Age BETWEEN 0 AND 120), CONSTRAINT CK_Users_Status CHECK (Status IN (0, 1)) ); GO CREATE TABLE dbo.Orders ( OrderId INT IDENTITY(1,1) NOT NULL, UserId INT NOT NULL, OrderDate DATETIME2 NOT NULL CONSTRAINT DF_Orders_OrderDate DEFAULT (SYSDATETIME()), TotalAmount DECIMAL(18,2) NOT NULL, CONSTRAINT PK_Orders PRIMARY KEY (OrderId), CONSTRAINT FK_Orders_Users FOREIGN KEY (UserId) REFERENCES dbo.Users (UserId) ON DELETE CASCADE ); GO这段脚本里有几个细节值得单独说明。第一每个约束都显式命名命名统一为“约束类型缩写_表名_列名”。约束名在架构内是唯一的不显式命名的话SQL Server会自动生成一串随机名字日后要查询、禁用、删除都非常痛苦。第二默认值约束用了SYSDATETIME()而不是GETDATE()前者精度更高语义也更准确。第三Age列用TINYINT并配CHECK约束既控制了存储空间又限制了非法范围。第四Status用TINYINT加CHECK枚举比字符串状态更紧凑查询和索引性能都会更好。2.2 表结构变更时的约束管理实际项目里很少有机会完全从零建表更多是给老表补约束、调约束、修数据。所以ALTER TABLE的几种变体必须吃透。给已有表添加CHECK约束最常见的是这种写法ALTER TABLE dbo.Users ADD CONSTRAINT CK_Users_Age CHECK (Age BETWEEN 0 AND 120);默认情况下这个语句会先扫描现有数据只要存在违反约束的行语句就会直接失败。如果数据库里已经有脏数据而你又想先把约束挂上去、之后慢慢清理可以用WITH NOCHECKALTER TABLE dbo.Users WITH NOCHECK ADD CONSTRAINT CK_Users_Age CHECK (Age BETWEEN 0 AND 120);注意WITH NOCHECK的意思是创建约束时不验证现有数据只对后续写入生效。这时候约束的is_not_trusted状态为1查询优化器也不会信任它来做简化。生产环境要谨慎使用这个选项它会让约束处于一种“名义上存在、实际上漏检旧数据”的状态。等脏数据清理完之后一定要用WITH CHECK CHECK CONSTRAINT把它恢复成受信任状态脚本我在第3章会给出。删除约束比较简单ALTER TABLE dbo.Users DROP CONSTRAINT DF_Users_Status;修改约束则没有一个ALTER CONSTRAINT语法通常都是先删除再新增。比如想把Age的CHECK范围从0-120改成18-120就是先删旧约束再加新约束。这里要提醒一句在生产环境改约束之前先把数据和影响面评估清楚留出回滚窗口。因为CHECK一旦转向更严格的范围所有违反新规则的行都会被强制挡在写入之外业务侧如果没有提前感知很容易引发线上事故。2.3 约束元数据查询与命名规范管理约束离不开元数据查询。我把这次复盘里真正用到的查询脚本整理了出来基本可以覆盖日常90%的需求。先看当前数据库里所有表的所有约束以及它们的启用和信任状态SELECT s.name AS SchemaName, t.name AS TableName, c.name AS ConstraintName, c.type_desc AS ConstraintType, CASE WHEN c.is_disabled 0 THEN Enabled ELSE Disabled END AS Status, CASE WHEN cc.is_not_trusted 1 THEN NotTrusted ELSE Trusted END AS TrustStatus FROM sys.objects t JOIN sys.schemas s ON t.schema_id s.schema_id JOIN sys.objects c ON t.object_id c.parent_object_id LEFT JOIN sys.check_constraints cc ON c.object_id cc.object_id WHERE t.type U AND c.type IN (PK, F, UQ, C, D) ORDER BY s.name, t.name, c.type_desc;这里sys.objects的type字段含义PK主键、F外键、UQ唯一约束、C CHECK约束、D默认值约束。sys.check_constraints里的is_not_trusted告诉我们CHECK是否受信任sys.objects.is_disabled则告诉我们约束是否被禁用。这两个字段是排查约束问题的关键证据第4章还会反复用到。如果想单独看某个表的外键关系包括引用了哪张表、哪一列可以查sys.foreign_keys和sys.foreign_key_columnsSELECT fk.name AS FKName, tp.name AS ReferencingTable, cp.name AS ReferencingColumn, tr.name AS ReferencedTable, cr.name AS ReferencedColumn FROM sys.foreign_keys fk JOIN sys.foreign_key_columns fkc ON fk.object_id fkc.constraint_object_id JOIN sys.tables tp ON fkc.parent_object_id tp.object_id JOIN sys.columns cp ON fkc.parent_object_id cp.object_id AND fkc.parent_column_id cp.column_id JOIN sys.tables tr ON fkc.referenced_object_id tr.object_id JOIN sys.columns cr ON fkc.referenced_object_id cr.object_id AND fkc.referenced_column_id cr.column_id WHERE fk.parent_object_id OBJECT_ID(dbo.Orders);这些查询脚本我建议直接保存到自己的工具库排查线上问题时会非常省时间。我自己的习惯是每次接到“数据对不上、外键加不上、约束没生效”这类工单第一件事永远是查元数据。先把约束的启用状态、信任状态、引用关系看明白再下手处理而不是一上来就盲目改数据。3. 数据库日常管理约束维护、备份恢复与索引整理3.1 约束状态维护NOCHECK与CHECK的实战约束上线之后不会一直安稳运行数据迁移、批量导入、甚至一次错误脚本都可能逼着你操作约束状态。最典型的就是大批量插入数据前先把外键和CHECK约束临时禁用插入完成后再恢复。-- 批量写入前禁用Orders表上的所有外键/CHECK约束 ALTER TABLE dbo.Orders NOCHECK CONSTRAINT ALL; -- 批量写入完成后重新启用并检查所有约束 ALTER TABLE dbo.Orders WITH CHECK CHECK CONSTRAINT ALL;不少人会搞混这两条命令的语义。第一条只影响后续写入它不会修复已经存在的脏数据。第二条是“启用并顺便全面验证现有数据”只要表里有任何违反约束的行语句就会报错并回滚。如果这个语句执行失败最稳妥的做法是先把脏数据查出来、修复掉然后再执行启用千万不要让库长期停留在“禁用约束”的危险状态。还有一种更隐蔽的场景当你想用TRUNCATE TABLE清空一张被子表引用的父表时会直接报错。原因在于TRUNCATE在事务日志里只记录页释放不触发DELETE逐行操作SQL Server不允许对存在外键引用的表执行TRUNCATE。常用的绕法是先禁用外键再TRUNCATE再恢复。但别忘了恢复之后跑一遍WITH CHECK CHECK CONSTRAINT ALL重新验证。我自己遇到这种场景还会顺手检查外键列的索引状态因为TRUNCATE后如果重建数据外键索引大概率也会重新产生碎片。3.2 备份恢复与数据完整性验证约束管理绕不开备份恢复。日常备份通常分完整备份、差异备份、日志备份各自解决不同时间粒度的恢复需求。这里不展开讲具体备份策略怎么配但要重点强调一个容易被忽略的关联约束的信任状态会跟着备份走。如果某个CHECK约束当初是用WITH NOCHECK加上去的那备份恢复之后它依然是不受信任的不会因为你有过一次备份就自动变干净。所以在数据库恢复之后我建议立刻做两件事。第一件运行DBCC CHECKDB验证物理和逻辑一致性DBCC CHECKDB (MyDB) WITH NO_INFOMSGS;第二件把is_not_trusted为1的约束全部重新检查一遍ALTER TABLE dbo.Users WITH CHECK CHECK CONSTRAINT ALL;如果这一步报错了说明表里确实存在不满足约束的数据需要静下心来把脏数据修完再启用。在真正的生产环境我宁愿花几个小时修数据也不愿意让约束带着“不受信任”的标签继续运行。原因很简单一个不受信任的约束在优化器眼里是“可以用但没有验证”的规则它既不能帮你拦截问题还会给你一种虚假的安全感。另外备份恢复还牵扯到恢复模式的选择。如果数据库处于完整恢复模式、并依赖日志备份做时间点恢复那么约束的外键引用检查会在写入路径上增加额外的查找成本。如果为了追求极高写入性能而禁用约束那恢复策略里就必须留出更频繁的完整性验证动作。这是一个需要在性能和一致性之间反复权衡的管理决策没有绝对正确的答案但一定要在事前想清楚。3.3 索引与统计信息维护主键和唯一约束会自动创建索引这些索引也会随着增删改产生碎片。碎片率过高时查询扫描的数据页变多IO明显变高。我常用的碎片检查脚本基于sys.dm_db_index_physical_statsSELECT OBJECT_NAME(ips.object_id) AS TableName, i.name AS IndexName, ips.index_type_desc, ips.avg_fragmentation_in_percent, ips.page_count FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, LIMITED) ips JOIN sys.indexes i ON ips.object_id i.object_id AND ips.index_id i.index_id WHERE ips.avg_fragmentation_in_percent 10 ORDER BY ips.avg_fragmentation_in_percent DESC;对于碎片率在5%到30%之间的索引执行REORGANIZE重组即可超过30%建议REBUILD重建。REBUILD会重建整个索引结构可能会对表产生较长锁持生产环境建议放在低峰期执行并尽量加上ONLINE ON来降低影响ALTER INDEX ALL ON dbo.Orders REBUILD WITH (FILLFACTOR 90, ONLINE ON);外键列的索引尤其容易被遗忘。但外键列碎片过高会直接拖慢父表的删除和更新性能。所以维护计划里不要只盯着主键索引外键索引也应当纳入同一个碎片检查清单。统计信息则关系到优化器对约束相关查询的估算准确度每周或者每次大数据量变更之后执行UPDATE STATISTICS是个稳妥的习惯。3.4 权限管控与例行维护作业的落地清单约束管理跟数据库权限强相关。添加或删除约束需要表的ALTER权限创建表需要CREATE TABLE权限。生产环境通常不建议给开发账号开放db_owner但约束变更又确实需要较高权限所以这里必须有一个机制兜底所有涉及约束的变更脚本走审核流程先在测试环境执行验证再上生产。我见过最危险的操作是运维为了解决“外键阻塞”问题直接批量禁用了所有外键约束处理完却忘了恢复等发现时数据已经横跨几个月各种不一致。为了避免这类事故自动化作业里最好加一道监控每天扫描sys.foreign_keys和sys.check_constraints只要发现is_disabled1或is_not_trusted1就发出告警。有了这道自动化兜底哪怕有人手滑禁用了约束也能在数据恶化之前被及时发现。SQL Server Agent是承担这些例行维护的主力。值得纳入作业计划的至少有三件第一每天跑一次碎片检测按阈值决定是否重组或重建索引第二每周跑一次DBCC CHECKDB和约束信任状态检查第三每天按备份策略执行备份并把备份日志发送给值班人员。约束检查虽然不像备份那么紧急但它直接跟数据质量挂钩放在作业里自动执行远比依赖人工抽查可靠。4. 实战避坑约束相关的常见问题与排查技巧4.1 外键添加失败多半是脏数据这是我排查频率最高的一类问题。执行添加外键的SQL时报错一般长这样The ALTER TABLE statement conflicted with the FOREIGN KEY constraint FK_Orders_Users. The conflict occurred in database MyDB, table dbo.Users, column UserId.翻译成人话就是Orders表里存在引用指向的UserId在Users表里根本找不到对应记录也就是典型的孤儿数据。排查脚本并不复杂SELECT DISTINCT o.UserId FROM dbo.Orders o LEFT JOIN dbo.Users u ON o.UserId u.UserId WHERE u.UserId IS NULL;拿到这批孤儿数据的Id之后再结合业务判断是删除、纠正还是归档。处理完重新执行ALTER TABLE通常就能顺利通过。这里要特别提醒如果外键引用的是复合主键排查时LEFT JOIN必须把所有引用列都关联上漏掉任何一列都会导致误判。我见过有同事只用一列去关联复合主键差点把完全正常的业务数据当成脏数据删掉。4.2 唯一约束与NULL的“坑”继续讲SQL Server唯一约束的NULL行为。前文提到SQL Server默认允许多个NULL共存所以像Email这种“可空但希望全局不重复”的列加上唯一约束后会有一个微妙问题多条Email为NULL的记录可以同时存在。这在大部分业务下没有问题但如果你期望“NULL也只能有一条”就得借助额外方案。比如用一个生成列把空值统一成空字符串再建唯一索引或者用过滤索引只对非空值做唯一约束CREATE UNIQUE INDEX UQ_Users_Email_NotNull ON dbo.Users(Email) WHERE Email IS NOT NULL;过滤索引的好处是既保证非空邮箱不重复又允许任意多条NULL记录存在。代价是查询条件里必须带上WHERE Email IS NOT NULL或者让查询条件匹配过滤索引的谓词否则优化器可能选择全表扫描而不是走这个索引。这类细节在写查询时很容易被忽略最好在索引设计阶段就想清楚。4.3 CHECK约束“不生效”的真相有一个很典型的报障场景开发说“我明明加了CHECK约束为什么还是能插入非法数据”排查之后往往发现两种原因。第一种是约束确实被禁用了或者从未被信任过。判断方法就是回到第2章给的查询脚本看is_disabled和is_not_trusted两个字段。第二种就是反复提到的NULL问题CHECK遇到NULL时返回UNKNOWNSQL Server不认为UNKNOWN是违反约束于是放行。举个具体例子ALTER TABLE dbo.Users ADD CONSTRAINT CK_Users_Age CHECK (Age 0);如果Age列允许NULLINSERT INTO dbo.Users (UserName, Age) VALUES (张三, NULL)照样会成功。要让约束真正把NULL也挡在门外通常需要改成ALTER TABLE dbo.Users ADD CONSTRAINT CK_Users_Age CHECK (Age IS NULL OR (Age 0));或者直接把Age设为NOT NULL从根源上关闭NULL通道。这个经验告诉我们设计CHECK约束时不能只考虑数值范围和枚举值必须把SQL的三值逻辑算进去。4.4 约束与性能的取舍经验最后聊一个偏性能的话题。约束不是免费的主键和唯一约束因为自动建索引写入时要维护索引结构外键约束在每次插入、更新、删除时都要确认引用存在CHECK约束还要计算表达式。但这些开销通常换来的是数据质量值得。真正需要做取舍的是两种特殊情况。第一种就是外键列没有索引。前面反复强调过父表删除被引用键时如果子表外键列没索引引擎只能全表扫描子表配合锁粒度放大极易形成阻塞和死锁。这类问题可以从sys.dm_db_missing_index_details查到缺失索引提示也可以直接遍历外键列表逐一确认是否存在对应索引。补上索引之后性能差异通常立竿见影。第二种是过度设计CHECK约束。有人会在CHECK表达式里调用用户自定义函数试图在数据库层完成复杂的格式校验。出发点没错但自定义函数的额外CPU开销以及优化器对函数不确定性的判断会导致每条DML都变慢得不偿失。我的建议是CHECK约束适合做确定性的简单规则复杂的业务校验应该在应用层多写一层而不是让数据库在每一行插入时执行消耗巨大的函数调用。最后分享一个小技巧。如果你接手的老库有一堆外键列没索引想批量补可以用下面的动态SQL一键生成CREATE INDEX脚本自己审一遍再执行SELECT CONCAT(CREATE INDEX IX_, fk.name, ON , OBJECT_SCHEMA_NAME(fk.parent_object_id), ., OBJECT_NAME(fk.parent_object_id), (, col_name(fkc.parent_object_id, fkc.parent_column_id), );) FROM sys.foreign_keys fk JOIN sys.foreign_key_columns fkc ON fk.object_id fkc.constraint_object_id WHERE NOT EXISTS ( SELECT 1 FROM sys.index_columns ic JOIN sys.indexes i ON ic.object_id i.object_id AND ic.index_id i.index_id WHERE ic.object_id fkc.parent_object_id AND ic.column_id fkc.parent_column_id );这段SQL会把所有没有索引覆盖的外键列找出来生成补索引脚本。我建议把生成的脚本先在测试库跑一遍确认执行计划真正用上索引之后再上生产。这个动作看着不起眼但确实能帮你避开不少被锁表搞到凌晨的夜晚。我个人在这次复盘里最大的体会是约束设计不是建表那一刻的任务而是贯穿整个数据库生命周期的管理对象。如果你也想快速提升库的数据质量先从查一遍sys.foreign_keys和sys.check_constraints的信任状态开始把那些is_disabled1和is_not_trusted1的记录整理出来逐个恢复成正常状态。这个动作本身通常就能避免大量潜伏的数据问题。