不能用 MySQL general_log 做后台操作审计,因其不区分用户、无业务上下文、不可过滤且性能开销大;应由应用层写结构化日志表,辅以触发器兜底。

直接结论:不要依赖 MySQL 通用查询日志(general_log)来记录后台管理员操作,它不区分用户、不结构化、不可过滤,且开销巨大;应由应用层主动写入结构化日志表,配合触发器或 ORM 事件做兜底。
为什么不能用 general_log 做后台操作审计
MySQL 的 general_log 确实能记录所有 SQL,但它根本无法满足后台系统对“谁在什么时间、通过什么页面、修改了哪条数据”的审计要求:
- 它不记录发起请求的用户 ID、IP、HTTP 路径,只有 raw SQL 和连接线程 ID
- SQL 中的参数是明文拼接的(如
UPDATE user SET name='admin' WHERE id=123),无法反查原始业务上下文 - 开启后 QPS 1000 的实例 CPU 上升 30%–50%,日志文件按小时级膨胀,磁盘极易打满
- 无法按「模块」「操作类型」「目标记录 ID」等维度快速检索,纯文本 grep 效率极低
推荐方案:应用层写入 + AFTER_UPDATE / AFTER_INSERT 事件监听
以 Yii2 为例(其他框架逻辑类似),核心是把日志写入时机从「数据库层」上移到「应用模型层」,确保每条日志都带业务语义:
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
- 在
backend/components/AdminLog.php中定义write()方法,提取$event->sender的类名、主键、变更字段($event->changedAttributes)和当前登录用户 - 在
backend/config/main.php的on beforeRequest中注册监听:\yii\db\BaseActiveRecord::EVENT_AFTER_UPDATE和EVENT_AFTER_INSERT - 日志表
admin_log必须包含user_id、route(如/admin/user/update)、description(结构化描述)、created_at - 避免在事务中同步写日志表——若日志表写失败导致主业务回滚,得不偿失;建议异步队列或至少设为
INSERT IGNORE容错
MySQL 层兜底:用触发器捕获关键表变更
当部分旧模块绕过 ORM 直连执行 SQL(如定时脚本、DBA 手动修正),应用层日志会漏掉。此时可在敏感表(如 user、role)上加触发器:
CREATE TRIGGER log_user_update AFTER UPDATE ON `user`
FOR EACH ROW
INSERT INTO admin_log (user_id, route, description, created_at)
VALUES (
COALESCE(@current_admin_id, 0),
'TRIGGER',
CONCAT('UPDATE user SET ',
GROUP_CONCAT(CONCAT(OLD.username, '→', NEW.username) SEPARATOR '; ')),
UNIX_TIMESTAMP()
);
- 触发器里无法直接获取 HTTP 用户,需提前在连接会话中设置变量:
SET @current_admin_id = 123; - 触发器性能敏感,只对核心表启用,且
description字段要做长度截断(避免超长写入失败) - 触发器不捕获
DELETE的原始数据,如需审计删除,必须先用BEFORE DELETE把整行存到影子表
容易被忽略的三个细节
真正上线后出问题的,往往不是主流程,而是这些边角:
-
admin_log表没加索引:至少要在(user_id, created_at)和(route, created_at)上建联合索引,否则按人查或按时间范围查直接卡死 - 日志描述里拼接了敏感字段(如密码哈希、手机号),必须在
write()中硬编码过滤字段列表:if (in_array($name, ['password_hash', 'phone'])) continue; - 没配
expire_logs_days或定时清理脚本,admin_log表半年后达千万级,SELECT变慢、备份变重、磁盘告警频发










