MySQL错误日志在5.7+默认每行开头含ISO格式UTC时间戳（如2024-03-15T08:22:13.123456Z），5.6及更早版本默认无时间戳；需用head查看或SELECT @@log_error等确认格式，无时间戳则grep无法按时间精准过滤。
MySQL 错误日志本身不带结构化时间字段（如 ERROR 1234 行前没有 ISO 格式时间戳），直接用 grep 按时间过滤会漏掉或错匹配——必须先确认日志格式是否含可解析时间戳。
确认 MySQL 错误日志是否自带时间戳
MySQL 5.7+ 默认错误日志（log_error 配置项指向的文件）每行开头是类似 2024-03-15T08:22:13.123456Z 或 2024-03-15T08:22:13Z 的 UTC 时间戳；5.6 及更早版本默认无时间戳，需开启 log_error_verbosity=3 并配合 log_timestamps=SYSTEM 才可能有（但依然不稳定）。
- 检查当前配置：
SELECT @@log_error, @@log_error_verbosity, @@log_timestamps; - 查看日志头几行：
head -n 5 /var/log/mysql/error.log，确认是否有形如2024-03-15T...的前缀 - 若无时间戳，
grep无法按时间过滤，只能靠日志轮转时间（如error.log.1）粗略定位
用 grep 提取指定日期范围内的日志行（含标准时间戳）
假设日志格式为 2024-03-15T08:22:13.123456Z [Warning] ...，且你要查 3 月 15 日 08:00 到 12:00 的所有行：
- 最简方式（精确到日）：
grep '^2024-03-15' /var/log/mysql/error.log - 按小时段（推荐）：
sed -n '/^2024-03-15T08:/,/^2024-03-15T12:/p' /var/log/mysql/error.log—— 注意结尾时间要写成T12:而非T12:00，否则会漏掉T12:00:xx开头的行 - 避免跨天问题：不要用
grep -A或grep -B，它们基于行号而非时间逻辑，极易截断上下文 - 时区注意：日志用的是
Z（UTC），若你本地是 CST，需把查询时间换算为 UTC 后再写表达式
用 awk 做更可靠的时间范围过滤（支持秒级精度）
当需要严格按时间戳比较（比如 08:22:13.5 到 08:23:47.2），grep 和 sed 都不擅长解析浮点秒，awk 更合适：
awk -F'[][:.]' '
$1"-"$2"-"$3"T"$4":"$5":"$6 >= "2024-03-15T08:22:13" && \
$1"-"$2"-"$3"T"$4":"$5":"$6 <= "2024-03-15T08:23:47" \
{print}
' /var/log/mysql/error.log
- 该命令拆分
2024-03-15T08:22:13.123456Z为字段，拼出不含微秒的 ISO 时间串用于字符串比较（ISO 字符串比较等价于时间大小比较） - 不依赖
strftime或外部命令，兼容性好；但要求日志时间戳格式统一、无空格错位 - 若日志中混有无时间戳的行（如 mysqld 启动信息），加
$1 ~ /^[0-9]{4}/做前置校验，跳过非法行
常见错误与绕过方式
实际操作中最容易卡在以下三点：
-
grep "2024-03-15"匹配到注释、SQL 语句里的日期字面量，不是日志时间戳 → 改用grep "^2024-03-15"锚定行首 - 日志被
logrotate切割后，error.log是软链，真实文件名含日期（如error.log-20240315）→ 先ls -l /var/log/mysql/error.log*确认活跃文件 - MySQL 进程以
mysql用户运行，而你用普通用户执行grep报Permission denied→ 加sudo，或让运维临时加读权限：sudo chmod o+r /var/log/mysql/error.log
真正难的不是写对一行命令，而是确认那行日志确实是你想查的错误——时间戳只是索引，关键得看后续内容是否含 ERROR、Crashed、Aborted connection 这类关键词。别只盯着时间，忘了看上下文。
