general_log仅适用于临时调试，非审计工具；它记录原始SQL但不记录执行结果、权限校验及连接成败，审计应使用audit_log插件或server_audit。
能开，但别当审计主力用——general_log 是调试开关，不是审计工具。它能记录所有客户端发来的原始 SQL，但不记录执行结果、权限校验过程、失败原因，也不区分成功/失败连接。真要审计，得搭配 audit_log 插件或 server_audit；临时抓一条语句、查个登录时间，它够快、够直接。
怎么动态开启 general_log（不用重启）
MySQL 8.0 支持运行时开关，只要权限够、配置对，秒生效：
- 必须有
SUPER或SYSTEM_VARIABLES_ADMIN权限（root 默认有） - 先确认输出目标：
SHOW VARIABLES LIKE 'log_output';，常见值是'FILE'或'TABLE' - 若为
'FILE'，检查general_log_file路径是否可写（默认在数据目录下，文件名类似localhost.log） - 若为
'TABLE'，确认mysql.general_log表存在且引擎正常（SHOW CREATE TABLE mysql.general_log;） - 执行：
SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = ON;（顺序不能反）
为什么开了却看不到日志？常见静默失败点
SET GLOBAL general_log = ON 只控制“记不记”，不决定“写哪”或“能不能写”。日志没出现，90% 是下面这几个环节断了：
-
log_output被其他会话改回'NONE'或'FILE'但路径不可写——查一次SHOW VARIABLES LIKE 'log_output';和SELECT @@general_log_file;就知道 -
mysql.general_log表引擎损坏或被设为只读（MySQL 8.0 中该表默认只读），INSERT会静默丢弃，无报错 - 用
SELECT * FROM mysql.general_log查不到新记录，可能因表锁、CSV 引擎写入卡住，或查询时表刚被清空过 - 日志写了但被截断：大 SQL 超过
max_allowed_packet，argument字段只存前缀
从 general_log 表里精准查某条 SQL
别用 LIKE '%UPDATE%' 这种模糊匹配——注释、字符串字面量全会误中。要准，得靠组合过滤：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 先圈时间范围：
WHERE event_time BETWEEN '2026-09-30 14:00:00' AND '2026-09-30 14:05:00' - 再锁用户：
AND user_host LIKE 'app_user@10.0.2.%' - 最后匹配语句结构：
AND argument REGEXP '^UPDATE[[:space:]]+orders[[:space:]]+SET'（注意开头锚定、空格类匹配） - 如果语句含换行或缩进，
REGEXP比LIKE更可靠；但别忘了argument是 TEXT 类型，长度受限
关掉它，比开它更重要
IO 压力和磁盘增长是真实存在的。高并发下，每秒几百条日志写入会让 I/O 利用率飙到 90%+，还可能拖慢主库响应。关的时候必须用动态方式：
- 执行：
SET GLOBAL general_log = OFF;（不是= 0或= 'OFF'，布尔值写法最稳） - 如果之前指定了
general_log_file，关掉后文件不会自动删除，得手动清理 - 别依赖配置文件里的
general_log = 1—— MySQL 8.0.23+ 默认持久化变量，重启后可能继承 ON 状态，务必确认SELECT @@PERSISTED.general_log;
真正做权限审计、操作溯源，general_log 只是过渡方案。它的日志没上下文、没状态码、没执行耗时，连“这条 SQL 成功没”都回答不了——这些，得靠 audit_log 或 server_audit 补上。
