如何设计SQL触发器确保数据修改时备注原因必须非空且提供详细修改原因？

本文共计1115个文字，预计阅读时间需要5分钟。

不能直接在SQL查询器中做非空校验并抛出通用错误——必须明确检查+inserted+和+deleted+表中对应字段的值，再用+RAISERROR+或+THROW+中断执行。

为什么 UPDATE/INSERT 必须显式检查原因字段是否为空

SQL Server 触发器不支持像 CHECK 约束那样声明式地限制“某列非空才允许写入”。即使你在表结构里没设 NOT NULL，业务上要求每次修改都填 reason（比如 modify_reason），就得靠触发器拦截非法操作。关键点在于：inserted 表只在 INSERT 和 UPDATE 时有数据，deleted 表只在 DELETE 和 UPDATE 时有数据；而 UPDATE 是唯一同时涉及两者的操作，所以必须分开判断。

• 对 INSERT：只查 inserted.modify_reason 是否为 NULL 或空字符串
• 对 UPDATE：要查 inserted.modify_reason 是否为空（因为新值在这张表），且通常忽略 deleted.modify_reason
• 对 DELETE：一般不强制填原因，但如果业务真有此要求，就查 deleted.modify_reason —— 但注意：这其实不合理，因为删除前用户未必填过该字段

如何写一个带原因校验的 AFTER UPDATE/INSERT 触发器

假设目标表是 orders，要求每次 INSERT 或 UPDATE 都必须提供非空的 modify_reason 字段（类型为 VARCHAR(200)）：

CREATE TRIGGER tr_orders_require_reason ON orders AFTER INSERT, UPDATE AS BEGIN IF EXISTS ( SELECT 1 FROM inserted WHERE modify_reason IS NULL OR LTRIM(RTRIM(modify_reason)) = '' ) BEGIN RAISERROR('modify_reason 字段不能为空或仅含空白字符', 16, 1); ROLLBACK TRANSACTION; RETURN; END END;

说明：

• 用 LTRIM(RTRIM(...)) = '' 排除纯空格输入，比只判 IS NULL 更严格
• RAISERROR 级别设为 16 是用户可捕获的错误级别，不会被当作系统严重错误中断连接
• 必须紧跟 ROLLBACK TRANSACTION，否则事务继续，校验形同虚设
• 这个触发器对 UPDATE 生效，但只校验新值；如果原记录没填原因、新记录也没填，它会拦住；如果原记录有原因、新记录清空了它，也会被拦住

容易踩的坑：误用 deleted 表、忽略多行影响、漏掉空格校验

常见错误现象包括：

• 在 INSERT 触发器里引用 deleted 表：语法合法但返回空结果集，导致校验永远通过
• 用 IF @reason IS NULL 这种标量变量方式处理 —— inserted 是表，不是单值，必须用 EXISTS 或 COUNT(*) > 0
• 只判 IS NULL，放行了 '  '（空格字符串），业务上等于没填
• 在触发器里调用 PRINT 或写日志表却不 ROLLBACK：用户看不到报错，还以为成功了
• 没考虑批量操作：一次 UPDATE 改 1000 行，只要其中任意一行 modify_reason 为空，整个事务就得回滚 —— 这是设计使然，不是 bug

INSTEAD OF 触发器能绕过这个限制吗

不能，而且更危险。虽然 INSTEAD OF 允许你完全接管逻辑，但如果你在其中漏掉对 modify_reason 的检查，或者忘记把它写进实际 INSERT/UPDATE 语句，那校验就彻底失效。更麻烦的是：INSTEAD OF 不自动参与外键约束和级联操作，容易破坏数据一致性。除非你明确需要重写整条语句（比如把 JSON 字段拆成多列入库），否则坚持用 AFTER + ROLLBACK 是最直白、最可控的方式。

真正难的不是写触发器，而是让所有开发人员理解：这个字段不是“建议填写”，而是数据库层的硬性守门员。一旦上线，任何绕过它的 ORM 批量更新、SSIS 包、甚至临时写的 UPDATE 脚本，都会失败 —— 所以文档和沟通成本，往往比代码本身还高。