SQL Server触发器中无法用DBCC INPUTBUFFER获取原始语句，应改用sys.dm_exec_requests与sys.dm_exec_sql_text（加WITH (NOLOCK)）联合查询sql_handle，或更可靠的CONTEXT_INFO由应用层主动设置；二者均需注意时效性、权限及截断问题。
SQL Server触发器里拿不到DBCC INPUTBUFFER返回的当前语句
直接在触发器里调用 DBCC INPUTBUFFER(@@SPID) 通常返回的是触发器自身的定义（比如 EXEC sys.sp_executesql 或空），不是用户执行的原始 SQL。这是因为触发器运行在语句执行完成后的上下文中，原始批处理已退出，输入缓冲区被覆盖或重置。
真正能稳定获取原始语句的路径，是结合 sys.dm_exec_requests 和 sys.dm_exec_sql_text，但必须在触发器内立即抓取——稍晚一点就可能查不到对应记录。
- 触发器中需用
@@SPID获取当前会话 ID - 必须立刻查
sys.dm_exec_requests中status = 'running'且session_id = @@SPID的那条请求（注意：INSERT/UPDATE/DELETE 触发时，该请求可能已转为suspended，所以建议放宽条件为status IN ('running', 'suspended')） - 拿到
sql_handle后，再用sys.dm_exec_sql_text解析出文本；若返回 NULL，说明句柄已失效，基本无解
触发器中调用sys.dm_exec_sql_text要加WITH (NOLOCK)
不加提示容易阻塞或被阻塞：触发器本身在事务中运行，而 sys.dm_exec_sql_text 底层依赖内部缓存结构，高并发下可能因锁等待超时或死锁失败。加上 WITH (NOLOCK) 是事实上的必需操作。
示例片段：
DECLARE @sql_handle VARBINARY(64);
SELECT TOP 1 @sql_handle = er.sql_handle
FROM sys.dm_exec_requests AS er WITH (NOLOCK)
WHERE er.session_id = @@SPID
AND er.sql_handle IS NOT NULL
AND er.status IN ('running', 'suspended');
<p>IF @sql_handle IS NOT NULL
BEGIN
SELECT TEXT FROM sys.dm_exec_sql_text(@sql_handle) WITH (NOLOCK);
END</p>
-
TOP 1是必要的——一个 SPID 在并行 DML 场景下可能对应多条dm_exec_requests记录 - 不能依赖
statement_start_offset/statement_end_offset提取子语句，触发器里它们常为 0，截取结果不可靠 - 返回的
TEXT是整个批处理，不是单条 INSERT/UPDATE 语句；若应用用sp_executesql拼接，你拿到的就是那段拼好的字符串
为什么CONTEXT_INFO比系统视图更可靠
系统视图方案有明显时效和权限短板：需要 VIEW SERVER STATE 权限；在连接池复用、异步作业、快照隔离等场景下 sql_handle 经常为空或错配。而 CONTEXT_INFO 是会话级变量，由业务代码主动设置，可控性高得多。
- 应用端在执行关键 DML 前，先执行
SET CONTEXT_INFO 0x...（把 SQL 文本 UTF-16 编码后转为VARBINARY(128)） - 触发器中用
CONVERT(VARCHAR(128), CONTEXT_INFO())取回原始字符串（注意截断风险） - 无需额外权限，不依赖运行时状态，也不受事务隔离级别影响
- 缺点是侵入业务逻辑——但比起不可靠的自动捕获，这是生产环境最常落地的方案
别指望在INSTEAD OF触发器里拿到原始语句的完整解析树
有人想通过 sys.dm_exec_query_plan 或 sys.dm_exec_text_query_plan 拿执行计划 XML 来反推语句，这条路走不通。触发器触发时，查询计划早已生成并缓存，但 plan_handle 与当前请求不一定关联，且 dm_exec_text_query_plan 不支持传入 sql_handle，只认 plan_handle。
更现实的做法是：接受“只能拿到批处理文本”这个限制，然后在应用层规范 SQL 写法（例如强制每条 DML 注释唯一 ID：-- TRK:ORD-2024-789），让触发器用 CHARINDEX 或正则（SQL Server 2017+）提取标记字段做后续判断。
真正难的从来不是怎么取，而是取到之后如何不误判——比如同一批里有多条 UPDATE，触发器怎么知道当前行变更是哪一句导致的。这点系统视图帮不上忙，得靠设计兜底。
