做不到。SQL Server触发器无法捕获导致更新失败的原始SQL语句，EVENTDATA()在DML触发器中返回NULL，sys.dm_exec_sql_text也不可靠；应改用SQL Server Audit、Extended Events等原生审计机制。
做不到。SQL Server 触发器无法捕获客户端执行的原始 SQL 文本，无论用 EVENTDATA()、sys.dm_exec_sql_text 还是其他内置方式，在 DML 触发器中都不可靠或直接返回 NULL。
为什么 EVENTDATA() 在 UPDATE/INSERT/DELETE 触发器里总是 NULL
EVENTDATA() 的设计目标仅限于 DDL（如 CREATE TABLE）和 LOGON 事件。在 DML 触发器中调用它，返回值是真正的 NULL，不是空字符串——哪怕你把它放在 AFTER UPDATE 最开头，结果也一样。XML 结构里没有 <sqltext></sqltext> 节点，只有 <objectname></objectname> 这类元信息。
为什么 sys.dm_exec_sql_text(@sql_handle) 拿不到用户原始语句
这个方案在触发器里极不稳定，原因有三：
-
@sql_handle取的是当前会话（@@SPID）最近一次执行的句柄，而触发器本身是嵌套执行，大概率拿到的是触发器内部语句（比如INSERT INTO AuditLog），不是用户发起的那条UPDATE - 并行 DML 场景下，
sys.dm_exec_requests可能返回多行，TOP 1不保证命中原始语句 - 需要
VIEW SERVER STATE权限，生产环境通常不开放；且返回的是整个批处理文本，如果应用用sp_executesql，你会看到一堆参数赋值，而非干净的UPDATE Users SET name = @p0 WHERE id = @p1
真正能记录原始 SQL 的替代方案
必须放弃触发器，改用 SQL Server 原生审计机制：
- SQL Server Audit：启用 STATEMENT 级别审计，可捕获 SQL 文本、执行者、时间戳，写入文件或安全日志，开销低且稳定
-
Extended Events：监听
sql_batch_completed或rpc_completed事件，开启collect_statement选项，能提取sql_text字段；比 Profiler 轻量，适合长期运行 -
Server Audit + Database Audit Specification 组合：可精确限定到具体数据库、用户、操作类型（包括失败的 UPDATE），支持
WHERE result = 'FAIL'过滤
触发器唯一能确认的，只是“某人在某张表上做了 DML”。至于那条 SQL 是从 SSMS 手敲的、还是 ORM 自动生成的、带什么参数、是否含子查询——全都不可能得知。想靠它做 SQL 级故障归因，方向就错了。
