SQL触发器无法可靠审计真实操作人，因其仅能获取连接账户而非业务用户；应使用数据库原生审计机制，如MySQL 8.0+的audit_log插件或Oracle统一审计，并严格管控日志安全。
SQL触发器无法可靠监控特定DBA账号的真实操作行为——它只能拿到连接层的账户（CURRENT_USER() 或 USER()），而无法识别应用透传的“操作人”或会话背后的实际身份。真要审计敏感用户行为，得绕开触发器，用原生审计机制。
MySQL里触发器看到的“用户”根本不是你想要的那个
比如应用统一用 app_user 连库，但前端传了 operator_id=alice；触发器里调 CURRENT_USER() 返回的永远是 app_user@%，不是 alice。你没法靠触发器把这条SQL和真实责任人挂钩。
- 触发器运行时没有访问客户端IP、应用名、执行堆栈的能力
-
USER()返回连接账号，CURRENT_USER()返回认证账号，两者在代理场景下常不一致，但都和业务用户无关 - 想记录操作人？必须由应用显式写入字段（如
updated_by），再在BEFORE UPDATE里校验，不能指望触发器“自动感知”
Oracle中用触发器捕获SQL文本风险高且不可靠
像从 v$session 和 v$sql 关联查出当前语句的做法（如 prev_sql_addr + hash_value）在高并发或绑定变量多的环境大概率查不到有效内容，甚至返回空或陈旧SQL。
-
v$session.prev_sql_addr只反映上一条执行语句，不是触发器正在响应的那条 - 如果SQL被硬解析/软解析多次，
v$sql中可能已无对应记录，查询直接失败 - 需要
PRAGMA AUTONOMOUS_TRANSACTION才能写日志表，但自治事务会绕过主事务一致性，日志和数据可能不同步
真正该用的方案：数据库原生审计功能
MySQL 8.0+ 用 audit_log 插件，Oracle 用统一审计（Unified Audit）或传统审计（AUDIT SELECT TABLE），它们在连接层就捕获用户、IP、时间、完整SQL，不依赖触发器。
- MySQL：
audit_log_format = JSON+audit_log_policy = ALL，日志路径需确保mysqld进程有写权限，否则插件加载报错Plugin 'audit_log' init function returned error - Oracle：
AUDIT SELECT, INSERT, UPDATE, DELETE ON SCOTT.EMP BY ACCESS;，审计记录进UNIFIED_AUDIT_TRAIL，查起来比触发器日志稳定得多 - 所有审计配置变更后必须重启服务或
FLUSH PRIVILEGES（MySQL）/EXEC DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL（Oracle）才生效
最常被忽略的一点：审计日志本身也是敏感数据，存储路径、访问权限、归档策略必须同步管控——否则日志文件被删或读取，等于没审。
