不能用触发器监控高危用户SQL执行，因其无法获取真实执行人、原始语句及客户端上下文；应改用sqlserver.sql_statement_completed扩展事件，按username字段精准过滤sa等高危账号，并通过异步方式关联会话信息补全上下文。
不能用触发器监控高危用户的SQL执行——触发器根本拿不到真实执行人、原始语句或客户端上下文。
为什么触发器里查不到高危用户的真实操作
触发器运行时，CURRENT_USER() 和 USER() 返回的是数据库认证账户（比如 app_user），不是你关心的“DBA”或“sa”；ORIGINAL_LOGIN() 在连接池复用、Kerberos代理、SSIS/Agent转发等场景下也经常为空或失真。更关键的是：sys.dm_exec_requests 和 sys.dm_exec_sql_text 在触发器中默认不可访问——即使显式授权，sql_handle 也早已失效，查到的很可能是下一条语句。
常见错误现象：
- 在触发器里写
SELECT @sql = text FROM sys.dm_exec_sql_text(@handle)，结果总是空或错乱 - 用
HOST_NAME()或APP_NAME()判断来源，但这些值可被任意伪造，且不随会话持久 - 以为
SESSIONPROPERTY('login_name')就是操作人，实际它只反映连接层账号，和业务身份完全脱钩
扩展事件才是唯一可行方案
必须放弃触发器，改用 sqlserver.sql_statement_completed 扩展事件，并按 username 字段过滤真实登录名。这个字段对应的是 SQL Server 登录账户，能准确识别 sa、dba_admin 等高危账号。
实操要点：
- 创建专用监控账号（如
audit_monitor），仅授予VIEW SERVER STATE，绝不给高危账号本身 - 事件过滤条件必须写成
WHERE ([username] = N'sa' OR [username] = N'dba_admin')，不能用database_principal_name或其他伪字段 - 目标必须选
event_file，避免ring_buffer内存溢出导致丢事件 - 启用
collect_system_time = ON，确保时间戳精确到毫秒，便于关联分析
如何补全缺失的上下文信息
扩展事件本身不带客户端IP、主机名、应用名等字段，但可以通过组合其他系统视图临时补全（需在事件触发后立即查）：
- 用
sys.dm_exec_sessions关联session_id查host_name、program_name、client_net_address - 用
sys.dm_exec_requests+sys.dm_exec_sql_text查完整语句（注意：必须在事件发生后几毫秒内执行，否则记录已消失） - 所有这类查询必须封装进异步作业或外部监听服务，绝不能塞进触发器——否则会拖慢主事务、引入锁竞争甚至死锁
真正难处理的从来不是技术实现，而是权限设计和数据归属：扩展事件捕获的是“谁以什么身份连进来并执行了什么”，但如果你的业务系统全用一个账号连接，那所有日志都会显示同一个名字——这时候再强的监控也白搭。必须推动应用层显式透传操作人，数据库层才能真正闭环。
