server_audit插件需开启performance_schema才能关联资源消耗，因其本身不记录cpu、io等指标，仅记录操作事件；必须通过performance_schema的events_statements_summary_by_user_by_event_name等表聚合分析资源消耗，并交叉audit日志识别高危行为。
server_audit 插件必须开启 performance_schema 才能关联资源消耗
audit 日志本身不记录 CPU、IO、内存等指标，它只记“谁在什么时间干了什么操作”。要识别“消耗资源最多”的账号，必须把 server_audit 的事件（如 QUERY_DDL）和 performance_schema 中的执行统计对齐。如果 performance_schema 关闭，events_statements_summary_by_user_by_event_name 这类表就为空，后续所有聚合分析都失效。
检查方式很简单：
SHOW VARIABLES LIKE 'performance_schema';
返回 ON 才算有效；若为 OFF，需在 my.cnf 中添加：
[mysqld] performance_schema = ON
重启后生效——很多团队配完 server_audit 却查不到资源数据，卡在这一步。
用 performance_schema 定位高资源消耗账号（非审计插件直接提供）
server_audit 不负责统计耗时或扫描行数，这部分得靠 performance_schema 的汇总表。重点关注以下三张表：
-
events_statements_summary_by_user_by_event_name：按用户+语句类型聚合，含SUM_TIMER_WAIT（总等待时间）、SUM_ROWS_AFFECTED等 -
events_statements_history_long：保留最近的长执行语句原始记录，可用于回溯具体 SQL -
users表：确认该用户是否真实存在且活跃（避免统计已禁用账号）
快速筛选 top 5 资源消耗用户（按总等待时间）：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
SELECT USER, SUM_TIMER_WAIT, COUNT_STAR, SUM_ROWS_AFFECTED FROM performance_schema.events_statements_summary_by_user_by_event_name WHERE USER IS NOT NULL AND SUM_TIMER_WAIT > 0 ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;
注意：SUM_TIMER_WAIT 单位是皮秒（10⁻¹² 秒），除以 10⁹ 得到毫秒，便于理解。
结合 audit 日志过滤出“高危+高消耗”组合行为
单纯看资源消耗，可能只是报表任务；真正异常的是“高消耗 + 高危权限 + 非常规操作”的组合。这时需要交叉比对：
- 先从
performance_schema找出消耗大的用户（如etl_user） - 再查该用户是否拥有
SUPER权限：SELECT Super_priv FROM mysql.user WHERE user = 'etl_user' AND host = '%'; - 最后用
server_audit日志（文件或 syslog）搜索该用户近期的QUERY_DDL或QUERY_DML记录，看是否执行了ALTER TABLE ... ENGINE=InnoDB、OPTIMIZE TABLE、大范围UPDATE等典型高 IO 操作
关键点：audit 日志中每条记录含 user、host、query、timestamp 字段（JSON 格式），可直接 grep 或导入 ELK 做条件聚合。别指望一条 SQL 同时查完所有维度——这是两个系统分工，硬拼会漏掉上下文。
容易被忽略的性能陷阱：audit 日志写入路径权限与轮转
即使配置了 server_audit_output_type = 'file' 和 server_audit_file_path，如果 MySQL 进程对目标目录无写权限，日志会静默失败，audit 功能形同虚设。更隐蔽的问题是磁盘满导致写入阻塞，进而拖慢整个 performance_schema 更新节奏。
验证方式分两步：
- 确认路径可写：
sudo -u mysql touch /var/log/mysql/audit.log.test && sudo -u mysql rm /var/log/mysql/audit.log.test - 检查日志是否滚动：
ls -lh /var/log/mysql/audit.log*，若只有单个超大文件（>1GB）且持续增长，说明没配logrotate或server_audit_file_rotate_size
生产环境必须设置轮转，否则一次批量导入就能让 audit 日志吃光磁盘——这比没开 audit 更危险，因为你会误以为“有日志=有保障”，实际早已停摆。
