开启 general_log 会引发 i/o 瓶颈、敏感信息明文泄露及磁盘失控，qps 1000 时日志写入超 2mb/s，rds 下还导致表级锁与 rto 延长；应优先使用 slow_query_log=0、业务层打点或云厂商 sql 审计。
因为开启 general_log 会无差别记录每一条客户端请求（含 SELECT、连接、断开、权限校验等），直接引发 I/O 瓶颈、敏感信息泄露和磁盘失控，不是“影响性能”，而是“随时可能拖垮服务”。
日志写入量随并发线性爆炸
每条简单查询至少产生 2–3 行日志（连接 + 查询 + 断开），QPS 1000 时日志写入轻松超 2MB/s。MySQL 进程需同步刷盘，general_log 成为磁盘 I/O 的单点瓶颈，SHOW PROCESSLIST 响应也会变慢——这不是“有点卡”，是监控指标肉眼可见恶化。
敏感信息明文落盘不可控
-
mysql -uadmin -ptest123这类命令里的密码会完整记入日志 - SQL 中的手机号、身份证号、JWT token、加密密钥全量暴露
- 日志文件无访问控制，只要能读取文件系统（如备份脚本、运维工具）就等于泄露数据库全部操作上下文
没有轮转机制，磁盘撑爆是时间问题
general_log_file 是普通文件，不支持自动 rotate；logrotate 无法安全重命名正在被 MySQL 持有句柄写入的文件。RDS 场景下更危险：写入 mysql.general_log 表会触发表级锁，大量连接卡在 Waiting for table level lock，且崩溃恢复时因 Crash 标记位导致 RTO 拉长——实例重启后要先回放整个日志表才能提供服务。
替代方案比硬开 general_log 更可靠
真要全量审计或排查，优先走这些路径：
- 用
slow_query_log+long_query_time = 0，它支持日志轮转、可过滤、写入开销低一个数量级 - 业务层加 SQL 打点（如 MyBatis 的
StatementHandler拦截），只录关键路径 - RDS 用户直接用云厂商提供的 SQL 审计功能（如阿里云 SQL 审计、腾讯云审计日志），底层已做脱敏与限流
临时调试时，务必用 SET GLOBAL general_log = 'ON' + log_output = 'TABLE'，复现完立刻 TRUNCATE TABLE mysql.general_log 并关掉——留着不关，等于在生产库门口堆了一桶汽油。
