答案：MySQL触发器无法直接获取操作人信息，需通过应用层传递。可使用会话变量（如@operator）在应用程序中设置操作人，并在触发器中读取该变量写入日志表；或结合数据库用户与应用用户的映射关系间接记录。日志表建议包含操作类型、新旧数据、操作人和时间等字段，用于审计追踪。注意会话变量需每次显式设置，连接池环境下易出错，且高并发时应避免日志影响主业务性能。
MySQL触发器本身无法直接获取操作人的信息，因为触发器执行时并不包含客户端用户或应用层用户（如登录系统的具体操作人）的上下文。但通过一些间接方式，可以在触发器中记录数据操作人员的信息。
使用SESSION变量传递操作人信息
在应用程序中执行数据变更前，先设置一个自定义的会话变量来标识操作人，比如：
SET @operator = 'zhangsan';UPDATE users SET name = 'new_name' WHERE id = 1;
然后在触发器中读取这个变量：
DELIMITER $$CREATE TRIGGER tr_log_update_users
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
INSERT INTO users_log (user_id, old_value, new_value, operator, operate_time)
VALUES (OLD.id, OLD.name, NEW.name, @operator, NOW());
END$$
DELIMITER ;
这样就能将操作人记录到日志表中。注意：@operator 是会话级别的变量，只在当前连接有效。
结合数据库账户与应用层用户映射
如果每个应用用户都对应一个独立的数据库账号（不常见），可以直接用 USER() 或 CURRENT_USER() 获取数据库用户：
INSERT INTO log_table (operator_db, action) VALUES (USER(), 'UPDATE');
更实际的做法是，在应用层维护一个映射表，把数据库连接用户和真实操作人关联起来，再通过日志或中间件记录对应关系。
日志表设计建议
为记录操作历史，建议创建专门的日志表，例如：
CREATE TABLE users_log (id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT,
old_data JSON,
new_data JSON,
operator VARCHAR(50),
action_type ENUM('INSERT','UPDATE','DELETE'),
operate_time DATETIME
);
在触发器中根据操作类型填充对应字段，便于后续审计追踪。
注意事项与限制
- 会话变量 @operator 需由应用程序显式设置，否则为 NULL
- 连接池环境下需确保每次操作前重置该变量，避免错乱
- 触发器不能记录应用层未提供的用户信息
- 高并发下应保证日志写入不影响主业务性能
基本上就这些方法，核心是让应用层主动传递操作人身份，数据库通过触发器配合完成记录。单纯依赖MySQL内部机制无法获取真实业务用户。实现时不复杂，但容易忽略变量生命周期管理。
