含大文本字段的触发器必然拖慢批量操作，必须重构逻辑或隔离处理；因其引发隐式转换、LOB复制、锁升级、日志膨胀及执行计划失真等问题，常规优化无效。
TEXT、NTEXT、IMAGE 已弃用，但现实中仍存在大量用 VARCHAR(MAX) 或 NVARCHAR(MAX) 存储大文本的表；这类字段一旦进触发器，极易因隐式转换、LOB 复制、锁升级或日志膨胀引发性能雪崩。直接结论：含大文本字段的触发器几乎必然拖慢批量操作，且无法通过常规“优化”手段挽回——必须重构逻辑或隔离处理。
为什么大文本字段会让触发器彻底失控？
触发器内访问 VARCHAR(MAX) 字段时，SQL Server 不会按需加载，而是默认将整个 LOB 值拉入内存并参与比较/赋值，哪怕你只检查 LEN(Notes) > 0：
- 隐式转换开销：若触发器中对
NVARCHAR(MAX)字段做LIKE、CONCAT或拼接字符串，会强制执行完整 LOB 复制，单行几 MB 就可能耗尽 tempdb 内存 - 锁粒度恶化：即使只读取大字段，也可能触发页锁升级（尤其在
AFTER INSERT中查INSERTED.Notes），阻塞并发写入 - 日志体积爆炸：修改含大文本的行时，触发器内任何对它的引用（哪怕只是
SELECT @tmp = Notes FROM INSERTED）都会导致完整 LOB 值写入事务日志，BULK_LOGGED 模式也救不了 - 执行计划失真：优化器无法准确估算 LOB 列的数据分布，常误判为高开销操作，导致本可走索引的查询退化为扫描
INSTEAD OF 触发器对 MAX 字段的陷阱
很多人想用 INSTEAD OF INSERT 控制大文本写入逻辑，但实际更危险：
- 必须手动重写整个
INSERT语句，漏掉INSERTED中的NVARCHAR(MAX)字段会导致数据截断且无提示 - 若在触发器里做
UPDATE target SET Notes = ISNULL(@notes, Notes)，SQL Server 会把 NULL 和非 NULL 的 LOB 值都视为变更，强制更新整列，触发完整日志记录 - 无法利用
TABLOCK提示：所有INSTEAD OF操作都在用户事务内完成，绕不开完整日志路径
真正能落地的替代方案
放弃在触发器里碰大文本字段——这不是妥协，是必要止损：
- 把大文本字段拆到独立关联表（如
OrderNotes），主表只留NoteId外键；触发器只操作轻量 ID，后续异步补全内容 - 用
OUTBOX模式：触发器仅插入一条轻量消息（OrderId, EventType, Timestamp）到专用消息表，由后台作业批量读取并处理大文本（如生成摘要、调用 NLP 服务） - 改用计算列 + 索引：若只需判断“是否有备注”，定义
HAS_NOTES AS CASE WHEN LEN(Notes) > 0 THEN 1 ELSE 0 END PERSISTED，并在其上建索引，触发器里查这个小整数列即可 - 导入前禁用触发器：
DISABLE TRIGGER tr_notes_audit ON Orders，导入完成再启用；若需补审计，用INSERT INTO AuditLog SELECT OrderId, Notes FROM Orders WHERE CreatedDate > @importStart批量补，不走触发器
如果必须保留现有触发器，最低限度加固
仅适用于无法立即重构的遗留系统，且需接受 20%+ 性能损失：
- 加
IF EXISTS (SELECT 1 FROM INSERTED WHERE DATALENGTH(Notes) > 100000)提前退出，避免对超大值执行后续逻辑 - 所有对
Notes的引用必须显式用DATALENGTH()替代LEN()（后者会忽略尾部空格且对 LOB 不稳定） - 禁用递归：
ALTER DATABASE currentdb SET RECURSIVE_TRIGGERS OFF，防止大文本更新引发自触发死循环 - 目标审计表必须使用
FILESTREAM或分离到只读文件组，避免与主表争抢 I/O
大文本和触发器是天敌，不是参数调优或索引能调和的。越早把 LOB 操作移出同步执行链，越早摆脱锁等待、日志满、tempdb 爆炸这些连锁故障。
