MySQL默认不记录权限变更历史，需依赖企业版audit_log插件、MariaDB的server_audit插件、binlog解析或外部快照比对来实现可追溯审计。
MySQL 没有内置的权限变更历史表
MySQL 本身不记录 GRANT、REVOKE 或 DROP USER 等操作的历史，mysql.user 表只存当前快照，不是审计日志。想查“谁在什么时候改了什么权限”，默认情况下——查不到。
常见错误现象：
– 运维说“权限昨天还好好的”，但 SELECT * FROM mysql.user WHERE User='app' 显示密码哈希变了、Super_priv 变为 N，却找不到谁干的；
– 开启了 general_log，但日志量爆炸、无结构、难过滤，且默认不记录权限语句的执行者主机/IP；
– 误以为 information_schema.ROLE_TABLES 或 performance_schema 里有变更记录，其实没有。
实操建议：
– 不要依赖 mysql.user 回溯变更；
– 避免开启 general_log 做长期审计（磁盘和性能代价高）；
– 真实生产环境必须启用 MySQL 企业版的 Audit Log 插件，或社区版替代方案（见下一条）。
用 audit_log 插件（企业版）或 MariaDB 的 server_audit 插件（社区友好）
MySQL 社区版原生不带审计插件，企业版的 audit_log 插件支持记录 GRANT、REVOKE、CREATE USER 等语句，并附带时间、用户、主机、SQL 文本。MariaDB 则通过 server_audit 插件提供类似能力，且开源免费。
使用场景：
– 合规要求（如等保、GDPR）明确需要权限操作留痕；
– 多人共管数据库，需划分责任边界；
– 定期做权限收敛前，先确认哪些账号近期被修改过。
实操建议：
– MySQL 企业版：确认已安装 audit_log.so，配置 audit_log_policy=ALL（或至少 OBJECTS,STATEMENTS），并设 audit_log_format=JSON 方便解析；
– MariaDB：安装 server_audit 插件后，设 server_audit_events='CONNECT,QUERY'，再用 grep 'GRANT\|REVOKE\|DROP USER' 过滤日志文件；
– 日志路径务必设在独立磁盘分区，避免写满 /var/lib/mysql；
– audit_log 插件不记录语句执行结果（成功/失败），只记发起动作——失败的 GRANT 也会进日志。
用 binlog 解析权限变更（仅限已开启且保留足够久）
MySQL 的二进制日志（binlog）会记录 DDL 和部分 DML，包括对 mysql.* 系统表的写入。如果开启了 binlog_format=ROW，UPDATE mysql.user 这类操作会被记录为行变更；如果是 STATEMENT 格式，则直接记录原始 SQL（如 GRANT SELECT ON db.* TO 'u'@'%'）。
参数差异：
– binlog_format=ROW 更安全但体积大，需用 mysqlbinlog --base64-output=DECODE-ROWS -v 解析，权限变更表现为对 mysql.user、mysql.db、mysql.tables_priv 等表的 UPDATE/INSERT/DELETE；
– binlog_format=STATEMENT 直观但可能因上下文缺失导致重放失败，且无法捕获隐式更新（如 ALTER USER 修改密码时未显式指定 authentication_string）。
实操建议：
– 先确认 SHOW VARIABLES LIKE 'log_bin' 为 ON，且 expire_logs_days 足够长（建议 ≥7）；
– 权限变更通常发生在低峰期，可结合时间戳定位：mysqlbinlog --start-datetime="2024-04-01 10:00:00" mysql-bin.000001 | grep -i "grant\|revoke\|drop user\|update.*mysql\.user"；
– 注意：FLUSH PRIVILEGES 不写 binlog，它只是重载内存缓存，不影响持久化状态。
权限变更监控必须配合外部工具链
单靠数据库内建机制很难做到实时告警、归档、比对和可视化。比如你发现 mysql.user 中某个账号的 Shutdown_priv 从 N 变成 Y，但 binlog 已过期、audit log 未开——这时候只能靠定期快照比对。
常见错误现象：
– 写个 cron 每小时 mysqldump --no-create-info mysql.user > user_$(date +%s).sql，但没校验数据一致性（空格、换行、注释干扰 diff）；
– 用 SELECT ... INTO OUTFILE 导出，但权限不足或路径不可写，静默失败；
– 忽略 mysql.proxies_priv、mysql.role_edges 等其他权限相关表，只盯 mysql.user。
实操建议：
– 用固定排序导出关键表：mysqldump --skip-extended-insert --order-by-primary mysql user db tables_priv columns_priv procs_priv proxies_priv role_edges；
– 每次导出后生成 SHA256 校验值，存入外部数据库或 S3，便于快速判断是否变化；
– 对比时用 diff -u 而非 diff，保留上下文行，方便定位哪一行权限字段变了；
– 如果用 Prometheus + mysqld_exporter，注意它不暴露权限字段，不能替代审计。
真正难的不是记录一次 GRANT，而是让每次变更都可追溯、可关联、可回滚。系统表没版本号，binlog 不保证永久留存，插件依赖部署方式——这些缝隙，得靠外部流程去焊住。
