MySQL触发器无法直接获取真实操作人，必须由应用层显式设置会话变量（如SET @current_user_id = 'u_12345'），触发器内通过IFNULL(@current_user_id, 'unknown')安全读取；USER()等函数仅返回连接账号，非业务用户。
MySQL触发器里不能直接拿到真实操作人
别指望 USER()、CURRENT_USER() 或 SESSION_USER() 返回张三或李四——它们只返回连接建立时的账号，比如 app@10.0.0.5。用连接池时，所有请求都走同一个数据库账号，触发器记录的永远是这个固定值，不是业务层登录的用户。
必须由应用层显式传值，触发器只负责读取
真正可行的做法是：应用在执行 INSERT/UPDATE/DELETE 前，先执行一条 SET @current_user_id = 'u_12345';（也可同时设 @client_ip、@request_id 等）。触发器内直接引用该变量，不加 SELECT，也不查表：
- 变量名必须以
@开头，如@current_user_id - 触发器中写
NEW.audit_user := IFNULL(@current_user_id, 'unknown');，避免 NULL 导致字段插入失败 - 变量作用域仅限当前连接，不会跨请求污染，但漏设就会残留上个用户的值
- ORM 如 MyBatis、Sequelize 可统一拦截 SQL 执行前注入
SET语句
容易踩的坑：变量未初始化、大小写、跨连接误用
@current_user_id 是会话级用户变量，不是系统变量（@@session.autocommit 那类），两者完全无关。常见错误包括：
- 应用某次直连调试或脚本执行没调
SET，触发器读到NULL，导致NOT NULL字段报错——必须用IFNULL()或COALESCE()兜底 - 误写成
SELECT @current_user_id：触发器里禁止显式查询，直接赋值即可 - 变量名大小写不敏感（默认），但建议统一小写，避免混淆
- 别把连接池复用当成“安全”，不同请求可能复用同一连接，变量值不可信，每次业务 SQL 前都得重设
替代方案对比：PostgreSQL 和 SQL Server 更灵活但依然要配合应用
PostgreSQL 支持 current_setting('app.user_id', true)，SQL Server 有 CONTEXT_INFO()，看起来更“原生”，但前提都是应用主动调用 SET。MySQL 没有等价机制，@ 变量就是唯一轻量且可靠的选择。如果日志里频繁出现 unknown，问题不在触发器，而在应用侧漏设变量——排查点永远在业务代码开头那行 SET 是否稳定执行。
