启用general_log需super或system_variables_admin权限，仅限临时调试，高并发下i/o压力大；日志可存表或文件，推荐log_output='table'便于过滤；查sql应按时间、用户、正则精确匹配；不适用于权限审计，因不记录授权决策，应使用audit_log插件。
开启 general_log 前先确认权限和影响
MySQL 的 general_log 能记录所有客户端发送的 SQL，但它不是审计专用功能，而是调试辅助开关。启用前必须确保你有 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限（MySQL 8.0.16+），否则执行 SET GLOBAL general_log = ON 会报错 ERROR 1227 (42501): Access denied。
它默认写入文件（general_log_file）或表（mysql.general_log），但无论哪种方式，高并发下 I/O 压力陡增，线上库严禁长期开启。只应在排查窗口期临时启用，且建议配合 log_output = 'TABLE' 避免日志文件失控。
-
SET GLOBAL log_output = 'TABLE';—— 切到表存储，便于后续用 SQL 过滤 -
SET GLOBAL general_log = ON;—— 立即生效，无需重启 - 查当前状态：
SELECT @@general_log, @@log_output;
从 general_log 表里快速定位特定 SQL
日志存进 mysql.general_log 后，表结构固定：字段包括 event_time、user_host、command_type（通常是 Query）、argument（实际 SQL 文本）。注意：argument 是 TEXT 类型，可能被截断（取决于 max_allowed_packet），大 SQL 或带长 JSON 的语句可能看不到全貌。
查某条具体语句，别直接 LIKE '%UPDATE users%'，容易误匹配注释或字符串字面量。优先用正则或分步缩小范围：
- 按时间圈定窗口：
WHERE event_time BETWEEN '2024-05-20 14:00:00' AND '2024-05-20 14:05:00' - 按用户过滤：
AND user_host LIKE 'app_user@10.0.1.%' - 查完整语句（避免模糊匹配）：
AND argument REGEXP '^UPDATE[[:space:]]+users[[:space:]]+SET'
为什么 general_log 不适合做权限追踪
general_log 只记录“谁发了什么”，不记录“谁被授权执行什么”。它无法告诉你这条 SQL 是否越权——比如一个只有 SELECT 权限的用户，如果通过 SQL 注入或应用层漏洞执行了 DELETE，general_log 会照记，但不会标注“该操作违反权限策略”。
真正做权限行为审计，应该用 MySQL 8.0+ 的 audit_log 插件（需单独安装）或企业版的 MySQL Enterprise Audit，它们能按账户、命令类型、结果状态（成功/拒绝）分类记录，并支持写入系统日志或远程 syslog。
-
audit_log记录的是“访问控制决策结果”，不是原始 SQL 流水 - 它能捕获
Access denied for user类错误，而general_log完全不记录失败请求 - 开启方式是加载插件：
INSTALL PLUGIN audit_log SONAME 'audit_log.so';，不是改系统变量
停用 general_log 后日志不会自动清理
关掉 general_log 只是停止写入，已存在的日志还在 mysql.general_log 表里，而且这个表默认是 CSV 引擎（MySQL 5.7）或 CSV/PERFORMANCE_SCHEMA 兼容表（8.0），不支持索引、分区或高效 DELETE。如果忘了清，表体积会持续膨胀，拖慢 SELECT 查询本身。
临时排查完务必清理：
- 清空表：
TRUNCATE TABLE mysql.general_log;（比 DELETE 快，且重置 AUTO_INCREMENT） - 如果用了文件输出，记得手动删
general_log_file指向的文件，再FLUSH LOGS防止残留句柄 - 检查是否误设为永久开启：查看配置文件中是否有
general_log = 1，线上环境应删除该行
最常被忽略的一点：即使你只开了 5 分钟，只要期间有批量导入或定时任务，mysql.general_log 就可能积累数万行——而它的查询性能在没索引时极差，下次想查反而卡住。
