直接开general_log不适合监控SUPER操作，因其记录所有语句导致IO压力大、磁盘迅速爆满、主库变慢，且不区分用户和操作类型，无法定位SUPER权限滥用；应使用server_audit插件，支持事件过滤、结构化日志和多目标输出，并需确保performance_schema开启、server_audit_events包含CONNECT和QUERY_DDL、日志路径权限正确。
为什么直接开 general_log 不适合监控 SUPER 操作
因为 general_log 会记录所有语句（包括心跳、健康检查、空查询），IO 压力大，磁盘几小时就爆满，主库响应明显变慢。它不区分用户、不过滤类型，根本没法定位谁在用 SUPER 权限干了什么。
真正有效的审计方式：server_audit 插件 + 事件过滤
MySQL Enterprise Audit（或 Percona 的开源 server_audit）才是生产环境该用的方案。它只记录指定事件，支持按用户、操作类型过滤，日志结构化（JSON），还能写入文件或 syslog。
-
INSTALL PLUGIN server_audit SONAME 'server_audit.so';必须先确认插件存在，否则报错Plugin 'server_audit' is not installed - 动态启用：
SET GLOBAL server_audit_logging = ON;，但重启后失效，必须写进my.cnf - 关键过滤配置：
SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DML';—— 必须包含QUERY_DDL，否则SET GLOBAL、INSTALL PLUGIN这类高危操作不会被记录 - 排除低风险账号可减日志量：
SET GLOBAL server_audit_excl_users = 'root,monitor';，但别把真正需要审计的 DBA 账号加进去
如何快速识别已发生的 SUPER 权限滥用
不用等日志滚动，立刻查当前实例有没有人在用 SUPER 干危险事：
- 查最近执行过
SET GLOBAL的连接：SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE 'SET GLOBAL%'; - 查是否加载过可疑插件：
SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_STATUS = 'ACTIVE' AND PLUGIN_NAME NOT IN ('mysql_native_password', 'caching_sha2_password'); - 查谁有
SUPER权限：SELECT user, host FROM mysql.user WHERE Super_priv = 'Y';，再对每个结果执行SHOW GRANTS FOR 'user'@'host';
audit_log 配置中最容易漏掉的三个细节
很多团队配完以为万事大吉，结果出事时日志里啥也没有——问题往往卡在这三处：
- 没开
performance_schema：audit 日志依赖它采集部分上下文，SHOW VARIABLES LIKE 'performance_schema';必须返回ON -
server_audit_events漏了CONNECT：无法发现暴力破解或代理登录（比如通过GRANT PROXY绕过权限检查） - 日志路径权限不对：
server_audit_file_path指向的目录，MySQL 进程用户（如mysql）必须有写权限，否则插件静默失败，server_audit_logging看起来是ON，实际没写入任何内容
真实风险不在“能不能配”，而在于“配了但没验证是否生效”。上线前务必用测试账号执行一次 SET GLOBAL max_connections = 500;，然后立刻去日志文件里搜这条语句——看不到，就是配置断点了。
