audit_log插件qps下降20%以上需立即调优:设audit_log_policy='logins'可压缩日志量90%+,qps影响降至1%以内;限定audit_log_include_accounts过滤用户;audit_log_file必须置于独立磁盘,严禁与datadir共盘。

audit_log插件开启后QPS掉20%以上,怎么救?
MySQL企业版的audit_log插件默认是同步写入、全量捕获,实测开销比general_log还高10%~15%。这不是配置没调好,而是它在Server层更深层拦截事件,还要做JSON序列化和权限校验——每条语句多走一整套流程。
-
audit_log_policy必须显式设为'LOGINS'或'ALL',别留空,默认行为不明确且可能全量记录 - 只审计登录/登出:设
audit_log_policy='LOGINS',日志量压缩90%+,QPS影响可降至1%以内 - 若必须记录DML,用
audit_log_include_accounts限定用户(如'admin@%'),避免普通应用账号被拖累 -
audit_log_file路径必须挂载在独立磁盘(如/mnt/logdisk/audit.log),严禁和datadir共盘,否则IO竞争会放大延迟
general_log=ON导致CPU空转等待,怎么关最稳?
general_log同步fsync写入是性能断崖的主因:每条SQL执行完必须等日志落盘才返回,高并发下小IO塞满磁盘队列,CPU干等。哪怕只开10分钟,也可能积压数万连接在Waiting for table level lock状态。
访问全球海洋潮汐模型。功能包括查询指定日期、时间和地点的潮高、潮汐极值及格点天气数据。
- 立刻执行
SET GLOBAL general_log = 'OFF',这是唯一能即时释放锁链的操作 - 检查
log_output值:RDS环境只能是'TABLE',但社区版可切回'FILE'(需确保MySQL进程对目标路径有写权限) - my.cnf里注释掉
general_log=1和general_log_file行,否则重启后自动恢复 - 别用
TRUNCATE TABLE mysql.general_log——MyISAM表下等于重建表,锁更久;InnoDB下也需元数据锁,反而加剧抖动
slow_query_log配置错,等于白开还吃性能
slow_query_log本身异步写入,开销温和,但配错就失效:比如long_query_time=0在生产环境等于打开general_log,所有语句都记;又或者没设min_examined_row_limit,导致SELECT 1这类无害查询也刷屏日志。
-
long_query_time按业务响应预期设(如1.0秒),绝不能为0 - 加
min_examined_row_limit=1000,过滤掉扫描行数少的“噪音”查询 -
log_output='FILE'比'TABLE'更轻量,避免写入mysql.slow_log表触发额外锁和buffer pool消耗 - 日志文件路径用
logrotate管理,配置copytruncate而非rotate,防止MySQL丢失文件句柄
Percona Server的server_audit插件怎么压开销?
Percona Server的server_audit插件虽比官方audit_log灵活,但server_audit_events漏配就会只记连接不记SQL——看似开了审计,实际关键操作全漏掉。
-
server_audit_events必须显式列出类型:'connect,query,query_dml,query_ddl',缺query就看不到任何SQL -
server_audit_output_type='file'比'syslog'更可控,但路径目录需chown mysql:mysql,否则插件静默失败 - 启用
server_audit_file_rotate_now=ON后,记得配合server_audit_file_rotate_size(如1048576)防单文件过大拖慢fsync - 别依赖
server_audit_logging=ON就万事大吉——它只控制开关,事件粒度、输出路径、轮转策略全得手动配齐










