mysql不提供完整操作日志系统，需组合触发器审计、general_log临时排查或外部工具（如percona插件、proxysql、应用层埋点）实现可靠审计。
MySQL 自身不提供完整的操作日志系统
MySQL 默认不记录 SELECT、INSERT、UPDATE、DELETE 这类语句的完整执行日志（即“谁在什么时候对哪张表做了什么”），general_log 虽能开启，但性能开销大、无结构化字段、不区分用户/客户端/IP，且默认关闭；binlog 只记录数据变更（DML/DDL）事件，格式为二进制或逻辑SQL，不包含执行者、时间戳精度低、也不记录查询类操作。
用触发器 + 日志表实现轻量级 DML 操作审计
适合中小系统，对关键表做增删改行为留痕。核心是：为每张需审计的表创建对应日志表，并在原表上加 BEFORE INSERT/UPDATE/DELETE 触发器，把操作上下文写入日志表。
示例：审计 users 表
CREATE TABLE users_audit_log (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
table_name VARCHAR(64) NOT NULL DEFAULT 'users',
operation ENUM('INSERT', 'UPDATE', 'DELETE') NOT NULL,
old_data JSON,
new_data JSON,
user_host VARCHAR(255),
client_ip VARCHAR(45),
exec_time DATETIME DEFAULT CURRENT_TIMESTAMP,
sql_text TEXT
);触发器中可用 USER() 获取当前账户，@@hostname 或解析 USER() 提取 IP；OLD/NEW 仅在对应事件中可用，需分别处理；sql_text 字段无法自动获取（MySQL 不暴露当前 SQL），建议由应用层传入或留空。
- 触发器不能跨库写日志表，日志表必须与原表同库
-
JSON_OBJECT()可用于构造old_data/new_data，但注意字段类型兼容性（如NULL值要显式处理） - 高并发写入可能成为瓶颈，日志表建议用
ENGINE=InnoDB并关闭autocommit批量提交
启用 general_log 是最直接但代价最高的方案
开启后所有客户端语句（含连接、断开、查询）都会记入文件或表，适合临时排查，不可长期运行。
启用方式：
SET GLOBAL general_log = ON; SET GLOBAL log_output = 'TABLE'; -- 或 'FILE' -- 日志存于 mysql.general_log 表（若选 TABLE）
注意点：
-
general_log记录的是连接线程视角的语句，不保证事务一致性（比如一个事务里的多条语句会分开记录） - 日志表无索引，查起来慢；文件模式下无法按用户/IP过滤，需靠外部脚本解析
- 默认不记录执行耗时、返回行数、错误码等，信息维度有限
- 生产环境开启后 QPS 下降明显，尤其高并发读场景
真正可靠的方案得靠外部工具或代理层
MySQL 本身不是审计数据库，完整操作日志需依赖外围能力：
-
Percona Audit Plugin：官方兼容插件，输出 XML/JSON 格式，可按用户、命令类型、数据库名过滤，支持远程 syslog，但需编译安装且 MySQL 8.0.19+ 已弃用 -
ProxySQL或MaxScale：在中间件层拦截并记录 SQL，能拿到真实客户端 IP、用户名、响应时间、结果集大小，但增加架构复杂度 - 应用层埋点：在 ORM 或 DAO 层统一拦截 SQL 执行，记录
Thread.currentThread().getStackTrace()、request.getRequestURL()等上下文，可控性最强，但覆盖不到直连 MySQL 的脚本或 DBA 操作
审计需求越强，越不能只依赖 MySQL 内置机制——触发器管不住 DDL 和跨表操作，general_log 吃资源又难分析，真正落地时往往要组合多种手段，且必须明确“谁需要看日志、看多久、用来做什么”，否则容易堆出一堆没人维护的冷数据。
