先查dmesg -T | grep -i "killed process"确认OOM killer日志，再比对时间戳与mysqld崩溃时刻；error log无OOM字样属正常，因进程被内核强制终止，不写入应用层日志。
MySQL崩溃后日志里找不到OOM字样怎么办
MySQL因内存耗尽（OOM）被系统 kill 时，mysqld 进程通常不会主动写入“OOM”或“Out of memory”到 error log，而是直接终止——此时 error log 最后一条记录往往是正常运行日志，甚至可能停留在几小时前。真正线索藏在系统层：dmesg -T 输出里才有内核 OOM killer 的完整决策日志，包括被 kill 的进程 PID、内存使用快照和触发原因。
实操建议：
- 立即执行
dmesg -T | grep -i "killed process"，确认是否为 OOM killer 所为；若匹配到类似Killed process 12345 (mysqld) total-vm:24567890kB, anon-rss:18901234kB，基本坐实 - 对比该时间戳与
mysqld崩溃时间（可通过systemctl status mysqld或journalctl -u mysqld --since "2024-05-20 14:00"确认） - error log 中若出现
Aborted connection或Got an error reading communication packets大量刷屏，可能是 OOM 前内存紧张导致连接异常中断，属间接信号
如何让MySQL error log保留足够多的崩溃前上下文
默认 MySQL error log 不记录堆栈（stack trace），更不生成内存快照（core dump）。想定位 OOM 根源，必须提前配置，否则崩溃后只能靠系统日志倒推，无法知道是哪个 SQL、哪个 buffer pool 操作或哪个插件吃掉了内存。
关键配置项（需重启生效）：
- 启用堆栈追踪：
log_error_verbosity = 3（MySQL 5.7+），确保 error log 包含 warning/error 级别以上的详细调用路径 - 允许 core dump：
core-file加入mysqld启动选项，并确保系统允许：ulimit -c unlimited+echo "/var/lib/mysql/core.%e.%p" > /proc/sys/kernel/core_pattern - 限制内存使用（预防性）：
innodb_buffer_pool_size不要超过物理内存的 70%，并搭配max_connections和tmp_table_size合理压降峰值内存需求
从 dmesg 日志中提取有效内存快照信息
dmesg 输出里的 OOM 条目不是日志摘要，而是带内存分布的诊断快照。重点看三类字段：
-
total-vm：进程虚拟内存总量，超 10GB 且远高于物理内存时需警惕 -
anon-rss：真正占用的物理内存（匿名页），若接近系统总内存（如 32GB 机器上显示 31GB），说明已无可用内存 -
pgpgin/pgpgout：页面换入/换出频次，OOM 前若持续高位，表明 swap 频繁、内存严重不足
示例片段：
dmesg -T | tail -20 [Mon May 20 14:23:11 2024] Out of memory: Kill process 12345 (mysqld) score 892 or sacrifice child [Mon May 20 14:23:11 2024] Killed process 12345 (mysqld) total-vm:28567890kB, anon-rss:30123456kB, file-rss:123456kB
这里 anon-rss:30123456kB ≈ 29GB，而机器只有 32GB，说明 mysqld 几乎独占全部物理内存，其他进程（包括内核）已无余量。
为什么不能只依赖 SHOW ENGINE INNODB STATUS 查内存
SHOW ENGINE INNODB STATUS 能看到 buffer pool 使用率、线程状态、锁等待等，但它反映的是 InnoDB 层的逻辑内存视图，不包含 mysqld 进程整体内存分布（如解析器、连接线程栈、临时表、query cache、第三方 UDF 或插件内存）。OOM 往往由非 InnoDB 组件触发，比如：
- 大量并发连接导致每个线程的
sort_buffer_size×max_connections爆炸 - 未优化的 JSON 查询触发
JSON_DETAILED内部缓存膨胀 - 启用
performance_schema且设置过高的performance_schema_max_memory_classes - 使用 Memcached 插件或自定义 UDF 未做内存释放
这些都不会体现在 SHOW ENGINE INNODB STATUS 的内存统计中，但会真实计入 anon-rss。所以 OOM 定位必须跳出 MySQL 内部命令，回到系统级观测。
OOM 崩溃最麻烦的不是找不到日志，而是日志之间没有时间对齐和因果链——dmesg 有时刻但无 SQL 上下文，error log 有 SQL 但无内存快照，core dump 有全貌但需要符号表解析。真正能串起来的，只有提前配好的 log_error_verbosity、core-file 和定期采集的 /proc/$(pidof mysqld)/status 快照。
