生产环境不应配置通用查询日志用于安全审计，因其仅为调试开关，开启会导致性能崩溃、磁盘耗尽及敏感信息明文落盘；应使用server_audit插件或MySQL 8.0+原生audit_log实现合规审计。
生产环境中不该配置通用查询日志做安全审计。它不是审计工具，而是调试开关；开启即意味着性能崩、磁盘爆、敏感信息明文落盘——没有折中方案，只有“开”或“不开”的选择。
为什么 SET GLOBAL general_log = ON 不能用于生产审计
临时开启看似无害，但实际会立刻触发三类不可控风险：
-
general_log记录每一条CONNECT、Query、Quit，包括SELECT和带密码的连接串（如mysql -uadmin -ptest123），且不脱敏 -
log_output = TABLE把日志写进mysql.general_log表，该表是CSV引擎，无索引、不能TRUNCATE、查一次SELECT * FROM mysql.general_log就可能卡住其他连接 -
SET GLOBAL设置重启即失效，但没人能保证下次重启前没人误删配置或改错参数——而你无法靠监控告警及时发现日志已静默关闭
真正该用的审计替代方案
合规审计要回答“谁、在什么时间、执行了什么操作、结果如何”，通用日志只回答“有条 SQL 过来了”，差了四个维度。正确路径是：
- 启用
server_audit插件（MariaDB Audit Plugin），它支持按账号过滤（server_audit_exclude_accounts = 'monitor@%'）、事件分级（CONNECT,QUERY_DML,QUERY_DDL）、JSON 格式输出，且可轮转 - 或 MySQL 8.0+ 企业版用原生
audit_log，设audit_log_policy = ALL+audit_log_format = JSON，再配合audit_log_rotate_on_size控制单文件大小 - 二进制日志（
log_bin）只记录变更类语句（INSERT/UPDATE/DELETE），配合binlog_format = ROW可还原具体行变更，适合事后追溯，但不记录SELECT或登录行为
如果非得临时开 general_log 查问题，必须守住的底线
仅限低峰期、短时间（≤15 分钟）、限定路径与权限，且操作后立即验证是否真正生效：
- 先确认路径存在且属主为
mysql用户：sudo mkdir -p /var/log/mysql&&sudo chown mysql:mysql /var/log/mysql - 运行：
SET GLOBAL general_log = 'ON'；SET GLOBAL log_output = 'FILE'；SET GLOBAL general_log_file = '/var/log/mysql/temp_general.log' - 立刻检查是否写入：
tail -f /var/log/mysql/temp_general.log—— 若无输出，说明log_output或路径权限出问题，不是“没生效”，而是静默失败 - 排查完立刻关：
SET GLOBAL general_log = 'OFF'，并手动rm /var/log/mysql/temp_general.log
真正的审计不是堆日志，而是选对插件、配好事件粒度、管住输出路径和生命周期。通用查询日志连“审计”两个字都担不起，它只是个开关，开得越久，离事故越近。
