mysql触发器无法区分实际操作用户，仅能获取连接账户信息，且不能拦截操作；审计应优先选用audit_log插件或cdc工具，避免依赖触发器做权限控制或复杂日志处理。
MySQL触发器本身不能区分操作用户
触发器在执行时看不到 USER() 或 CURRENT_USER() 以外的上下文，且无法感知连接层的认证用户（比如应用用统一账号连库，实际操作人是前端传来的ID）。更关键的是：触发器运行在语句级，而权限校验发生在语句执行前——你没法在触发器里“拦截”或“拒绝”操作，只能事后记录或抛错。
常见错误现象：ERROR 1442 (HY000): Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，试图在 AFTER INSERT 里更新同一张表就直接报错。
- 触发器里的
USER()返回的是连接账户（如'app@10.0.1.5'），不是业务用户ID - 想靠触发器做审计日志？可以，但必须把用户标识作为字段显式传入（比如应用层写入
operator_id到数据行） - 想阻断非法操作？别用触发器，该用
BEFORE触发器 +SIGNAL抛异常，但仅限简单规则（如禁止删除已审核记录），复杂逻辑会拖慢所有DML
审计日志该开 general_log 还是 audit_log 插件
MySQL自带的 general_log 记录所有语句，包括连接、查询、管理命令，但它不带用户身份映射（只记连接账号），且 I/O 开销大，生产环境基本不敢开。真正能落地的审计方案得用官方 audit_log 插件（企业版）或 Percona Server / MariaDB 的开源替代品。
使用场景：合规要求留存“谁在什么时候改了哪条记录”，且需防篡改。
-
audit_log插件默认记录USER()、HOST()、时间戳、SQL语句原文、影响行数，支持 JSON 或 XML 格式输出到文件或 socket - Percona Server 的
audit_log兼容 MySQL 8.0，但需手动安装；MariaDB 用server_audit插件，配置项名不同（如server_audit_logging=ON） - 注意路径权限：
audit_log_file指定的日志路径必须让mysqld进程可写，否则插件加载失败，错误信息是Plugin 'audit_log' init function returned error
用触发器补全审计字段时，NEW 和 OLD 的坑
触发器里想自动填充 created_by、updated_at 等字段，看似简单，但 NEW 和 OLD 的可用性取决于触发时机和语句类型。比如 INSERT 没有 OLD，DELETE 没有 NEW，而 UPDATE 两者都有——但如果你在 BEFORE UPDATE 里改了 NEW.updated_at，它真会生效；如果在 AFTER 里改，就无效。
-
BEFORE INSERT可安全设置NEW.created_at = NOW()、NEW.created_by = USER() -
BEFORE UPDATE中若需记录操作人，得靠应用传值（如NEW.operator_id），不能依赖USER()—— 因为连接账号是固定的 - 避免在触发器里调用函数如
NOW()多次：MySQL 8.0+ 对同一条语句内多次调用返回相同时间戳，但低版本可能有微秒级偏差
审计数据落库 vs 落文件，性能与可靠性怎么权衡
把审计日志写进数据库表（比如 audit_log_records），看着方便查，但高并发下容易成瓶颈：每条 DML 都要额外一次 INSERT，事务变长，锁竞争加剧。而写文件由 MySQL 异步刷盘，吞吐高，但检索困难，还得额外开发解析工具。
- 落库方案必须加索引：
CREATE INDEX idx_time_user ON audit_log_records(created_at, operator_id)，否则按时间范围查日志直接全表扫 - 落文件方案要注意磁盘满风险：
audit_log_file_size和audit_log_rotate_on_size必须配，否则单文件滚大后难处理 - 真正复杂的审计需求（如关联用户表查姓名、过滤敏感字段值），别硬塞进触发器或日志插件——应该用 CDC 工具（如 Debezium）捕获 binlog，再由外部服务做富化和投递
最常被忽略的一点：审计日志本身也要防删改。文件模式下需用只追加权限（chattr +a）；数据库模式下，审计表必须设为 READ ONLY 或用单独账号隔离写权限——否则管理员自己就能清空记录。
