mysql general_log需开启并设为文件输出才能高效按时间筛选；其日志行首为iso8601时间戳，多行sql需按时间戳分块提取；awk可精准切片时间段，但须锚定行首且注意语句完整性。
确认 general_log 是否开启且日志格式为文件
MySQL 的 general_log 默认关闭，即使开启，也可能以表形式（mysql.general_log）记录，而表格式不支持按时间范围高效筛选——因为该表没有索引，且时间字段是 event_time（datetime 类型），但 MySQL 不会自动为它建索引。更关键的是：**只有日志写入文件时，才能用系统工具（如 awk、sed、grep）做精准时间切片**。
检查当前配置：
SHOW VARIABLES LIKE 'general_log%';
若 general_log_file 指向一个路径（如 /var/lib/mysql/general.log），且 general_log = ON，说明日志正写入文件，可继续；若 log_output = 'TABLE'，请先执行：
SET GLOBAL log_output = 'FILE';<br>SET GLOBAL general_log = 'OFF';<br>SET GLOBAL general_log = 'ON';
注意：切换输出方式后，旧的表日志不会自动转出，仅影响后续新记录。
理解 general_log 文件的时间戳格式与结构
MySQL 写入文件的每条记录形如：
2024-05-22T14:23:18.123456Z\t123\tQuery\tSELECT * FROM users WHERE id = 1
关键点：
- 第一字段是 ISO8601 时间戳（带微秒和 Z 时区标识），后面紧跟制表符
\t - 第二字段是线程 ID，第三是命令类型（
Query、Connect、Quit等），第四起是 SQL 或事件内容 - 时间戳是严格按行首排列的，但**不是每行都带时间戳**：比如多行 SQL 中的换行会被原样保留，后续行无时间前缀
这意味着不能简单用 grep '2024-05-22' ——可能匹配到 SQL 内容里的日期字面量。必须锚定行首时间戳。
用 awk 提取指定时间段的完整语句块
由于日志中一条 SQL 可能跨多行（尤其含换行的存储过程或长 JSON），只截取带时间戳的行会丢指令。稳妥做法是：先标记所有带时间戳的行位置，再把从该行开始、到下一个时间戳行（或文件末尾）之间的所有内容视为一个逻辑操作单元。
例如提取 2024-05-22 14:00:00 到 14:30:00 的全部操作：
awk -v start="2024-05-22T14:00:00" -v end="2024-05-22T14:30:00" '
/^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}/ {
if ($1 >= start && $1 <p>说明：</p>
-
/^[0-9]{4}-.../匹配行首时间戳，避免误触 SQL 内容 - 只比较到秒级（忽略微秒和 Z），因
start/end未带微秒，字符串比较仍可靠（ISO 格式保证字典序 = 时间序） - 一旦进入目标时段，就持续输出后续非时间戳行，直到遇到下一个时间戳行才重新判断
如果日志量大，建议先用 head -n 100000 试跑，避免长时间阻塞。
过滤出特定类型的指令（如只看 DELETE 或慢查询）
提取后常需进一步聚焦。注意：general_log 不记录执行耗时，所以“慢查询”只能靠人工识别关键词（如含 SLEEP(、明显全表扫描的 WHERE 条件）；但操作类型可直接匹配第三字段：
例如只保留 Query 类型中的 DELETE 语句：
awk '/^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}/ && $3 == "Query" && tolower($0) ~ /delete/ {print; getline; while (!/^[0-9]{4}-/ && NF>0) {print; getline}}' /var/lib/mysql/general.log
更实用的做法是：先用上一步提取出时间段全量，再管道给 grep -A 2 -i "delete\|update\|drop" 查看上下文。
容易被忽略的一点：general_log 记录的是客户端发来的原始指令，不含注释展开、参数化占位符替换，也**不反映实际是否执行成功**——失败的语法错误也会记进来，但权限拒绝类错误可能只出现在 error_log 中。
