MySQL默认不记录权限变更，需通过performance_schema确认：先查performance_schema是否启用，再启用statement/abstract/account_management仪器及events_statements_history_long消费者，最后查询events_statements_history_long中GRANT语句并结合USER、HOST、SQL_TEXT分析。
怎么确认 MySQL 是否在记录权限变更操作
MySQL 默认完全不记录 GRANT、CREATE USER、DROP USER 这类操作，除非你主动启用审计能力。别指望 general_log 或 slow_query_log 能可靠捕获——它们没上下文、不关联用户身份、容易漏掉关键语句，且无法区分是人工执行还是 SQL 注入触发。
8.0.14+ 的可行方案是用 performance_schema 抓取 account_management 类事件：
- 先确认
performance_schema已开启：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'返回ON - 启用仪器：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'statement/abstract/account_management' - 打开消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%'（不是只开events_statements_current，得开events_statements_history_long）
如何从 performance_schema 查到可疑的 GRANT 行为
权限提升往往不报错，只是悄悄执行了一条高危 GRANT。重点不是“有没有 GRANT”，而是“谁对谁授了什么权”。
查最近 1 小时内所有 GRANT 语句的示例：
SELECT EVENT_ID, USER, HOST, SQL_TEXT, TIMER_START FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE 'GRANT%' AND TIMER_START > UNIX_TIMESTAMP(NOW() - INTERVAL 1 HOUR) * 1000000000;
关键过滤点：
-
HOST字段是否为非预期值（如'%'、'10.0.0.%'、'::1'），尤其当正常运维人员只从固定内网 IP 操作时 -
SQL_TEXT是否含SUPER、REPLICATION CLIENT、FILE、SHUTDOWN等高危权限 -
USER是否为低权限账号（如应用账号'app'@'192.168.5.10'却执行了GRANT ALL ON *.*）
为什么不能只依赖 SHOW GRANTS 查问题
SHOW GRANTS FOR 'user'@'host' 只反映当前权限快照，没法告诉你“这个权限是谁、什么时候、通过什么方式加上的”。一次成功的权限提升可能已经删掉原始语句痕迹，或通过代理、中间件、存储过程间接执行，SHOW GRANTS 完全看不到路径和时间线。
真正要定位异常行为，必须结合：
- 时间戳（
TIMER_START是纳秒级，别用NOW()直接比，要用UNIX_TIMESTAMP换算） - 执行者身份（
USER+HOST，注意CURRENT_USER()和USER()区别） - 语句原文（
SQL_TEXT，看是否带变量、拼接痕迹，判断是否自动化脚本或注入）
排查时最容易被忽略的细节
很多团队开了 performance_schema 却查不到记录，问题常出在三个地方：
-
events_statements_history_long默认容量有限（通常 10000 条），高频环境会快速覆盖，得提前调大performance_schema_events_statements_history_long_size -
account_management仪器只捕获抽象语法层事件，不抓INSERT INTO mysql.user这种绕过语法校验的直接表修改 - 如果用户用的是
DEFINER存储过程执行GRANT，实际USER字段显示的是定义者，不是调用者——得连同OBJECT_SCHEMA和OBJECT_NAME一起查
真正有效的监控，不是等事后再翻日志，而是把 performance_schema 查询逻辑做成定时巡检脚本，并对 HOST 和 SQL_TEXT 做规则匹配告警。
