MySQL触发器中CURRENT_USER()返回定义者而非操作者，记录操作人必须用USER()并截取用户名，或由应用层显式传值。
触发器里直接用 CURRENT_USER 会记录错人
在 MySQL 触发器中调用 CURRENT_USER()，返回的是执行触发器的「定义者权限用户」，不是实际发起 DML 操作的用户。比如你用 admin@localhost 创建了触发器，哪怕 app_user@10.0.1.5 执行了 INSERT，触发器里 CURRENT_USER() 仍返回 admin@localhost。
真正要记录操作人，得用 USER() —— 它返回连接时认证的用户名和主机，才是真实发起请求的客户端身份。
-
CURRENT_USER()：看触发器定义者的账号（DEFINER），受SQL SECURITY设置影响 -
USER()：看当前连接是谁连进来的，不受触发器定义者影响 - 如果触发器设为
SQL SECURITY DEFINER（默认），CURRENT_USER()几乎总是错的
MySQL 触发器中安全记录操作人信息的写法
必须用 USER()，且建议截断长度、处理 NULL，并存入预设字段（如 updated_by 或 created_by）。
示例（BEFORE INSERT）：
DELIMITER $$ CREATE TRIGGER log_insert_user BEFORE INSERT ON orders FOR EACH ROW BEGIN SET NEW.created_by = SUBSTRING_INDEX(USER(), '@', 1); SET NEW.created_at = NOW(); END$$ DELIMITER ;
-
SUBSTRING_INDEX(USER(), '@', 1)提取用户名部分，避免主机名过长或含特殊字符 - 不要用
NEW.created_by := USER()—— 直接赋值可能因字段长度不足报错 - 确保目标字段（如
created_by）类型是VARCHAR(64)或更宽，MySQL 用户名最大 80 字符，但实际通常 ≤32
PostgreSQL 怎么办？没有 CURRENT_USER 就不能用？
PostgreSQL 的 CURRENT_USER 是会话级别的当前角色（role），它确实能反映执行语句时的有效角色，但要注意：如果用了 SET ROLE 或通过 SECURITY DEFINER 函数调用，它可能不是原始连接用户。
更可靠的是 SESSION_USER（登录时指定的角色）或 CURRENT_USER + 配合应用层显式传参。不过 PostgreSQL 触发器不支持直接获取客户端 IP/用户名，除非：
- 启用
log_line_prefix = '%u %h '并解析日志（不推荐用于业务逻辑） - 用
pg_stat_activity关联pid查当前会话（性能差，禁止在触发器里查） - 最佳实践：由应用层把
current_user作为参数显式传入 DML（如INSERT INTO ... (..., updated_by) VALUES (..., current_setting('app.user'))），再配合SET app.user = 'alice'
容易被忽略的兼容性和权限坑
USER() 在 MySQL 中始终可用，但某些托管环境（如 AWS RDS、阿里云 PolarDB）可能禁用 USER() 的主机部分，或返回 ''@'' —— 这时候只能靠应用层透传。
- RDS for MySQL 默认关闭
log_bin_trust_function_creators，若触发器含函数调用（如SUBSTRING_INDEX），需提前设置该变量或授予对应权限 - 如果表用了列加密（如
AES_ENCRYPT），别在触发器里对USER()做加密运算——密钥管理复杂且易出错 - Oracle 和 SQL Server 没有等价的内置函数；Oracle 用
USER（静态值，不可靠），SQL Server 用SUSER_SNAME()，但都受限于执行上下文
真实场景里，数据库层记录操作人只是兜底手段；关键操作仍应由应用统一注入用户上下文，数据库触发器只做轻量校验与补全。
