必须在存储过程中显式写日志，因触发器仅响应dml操作，无法捕获存储过程调用、参数及调用者信息；安全审计需硬编码过程名、应用传用户、字符串化参数、单点时间采样，并批量写入日志。
不能靠触发器捕获存储过程调用行为，必须在存储过程中显式写日志。 触发器只响应 INSERT/UPDATE/DELETE 等 DML 操作，对 EXEC usp_UpdateOrder 这类调用完全无感——它连“谁调了过程、传了什么参数”都看不到。
为什么触发器和存储过程审计不能配合使用
常见误解是：给业务表加个 AFTER INSERT 触发器，就能反向追踪到是哪个存储过程改的数据。实际根本做不到：
- 多个存储过程（如
usp_CreateOrder和usp_ImportBatch）可能都操作同一张Orders表，触发器日志里只有表名和时间，无法区分来源 - 触发器中查不到
@@PROCID或OBJECT_NAME(@@PROCID)，SQL Server 里这些值在触发器上下文中为 NULL - 若在触发器里尝试调用
ERROR_MESSAGE()或读取会话变量，多数数据库直接报错或返回空 - MySQL 的触发器甚至禁止执行任何 SELECT（除从 NEW/OLD），更别说跨表查调用栈
存储过程里怎么安全写审计日志
真正可控的方式，是在每个关键存储过程的开头和结尾手动插入日志。不是“配合触发器”，而是“绕过触发器”：
-
audit_log表必须包含硬编码的proc_name字段（比如'usp_ProcessInvoice'），别依赖OBJECT_NAME(@@PROCID)—— 它在嵌套调用或动态 SQL 下不可靠 - 用户标识优先用应用传入的
@user_login参数， fallback 到ORIGINAL_LOGIN()（SQL Server）或session_user（PostgreSQL），不用CURRENT_USER() - 参数记录用
CONCAT拼字符串：CONCAT('@order_id=', @order_id, ', @status=', @status)，别查系统视图拼参数名 - 时间统一用局部变量赋值：
DECLARE @log_time DATETIME2 = SYSDATETIME();，避免多次调用函数导致微小偏差 - 日志写入必须和主事务共存亡：放在事务内，但用
SET XACT_ABORT OFF防止日志失败导致整个业务回滚
高频批量场景下避免性能崩盘
像导入 1000 条订单这种操作，绝不能在循环里每条都 INSERT INTO audit_log：
- 先写入临时表：
CREATE TABLE #audit_temp (proc_name VARCHAR(128), params VARCHAR(8000), ...) - 循环中只做
INSERT INTO #audit_temp，不碰磁盘 - 主逻辑完成后，一次性
INSERT INTO audit_log SELECT * FROM #audit_temp - 如果审计表本身有高并发写入压力，考虑用
WITH (TABLOCK)提升批量插入吞吐
最容易被忽略的一点：审计日志不是越全越好，而是越准越有用。硬编码过程名、应用透传用户、参数字符串化、时间单点采样——这些看似“笨”的做法，在嵌套调用、连接池复用、动态 SQL 场景下，反而比任何自动推导都可靠。
