MySQL被OOM Killer终止的典型迹象是服务器突然无响应、服务消失且错误日志无退出记录，需立即检查dmesg或/var/log/messages确认“Killed process mysqld”字样。
MySQL进程被OOM Killer干掉的典型迹象
服务器突然无响应、MySQL服务消失、系统日志里找不到MySQL主动退出记录——这时候先别急着查mysqld错误日志，直接看/var/log/messages或dmesg -T输出。如果看到类似Out of memory: Kill process 12345 (mysqld) score 892 or sacrifice child这样的行，基本可以确定是OOM Killer动手了。
注意：mysqld自己的错误日志（比如/var/log/mysql/error.log）通常**不会记录被杀过程**，它可能只停留在“正常启动”或“最后一条查询”，甚至完全空白。别在那反复翻error.log找线索。
- 用
dmesg -T | grep -i "killed process"快速确认是否触发OOM - 检查
/proc/meminfo里的MemAvailable值，低于500MB就非常危险 - OOM Killer选中
mysqld不是随机的，它的oom_score_adj默认较高（尤其在容器里没调过）
为什么MySQL容易成OOM Killer头号目标
不是MySQL写得差，而是它太“诚实”：配置里写的innodb_buffer_pool_size、sort_buffer_size、join_buffer_size等，都是**每个连接都可能分配**的内存上限。100个并发连接，sort_buffer_size=4M就会多占400MB——而这些内存不计入Linux的RSS统计主路径，但实实在在吃物理内存。
更隐蔽的是临时表：当tmp_table_size和max_heap_table_size设得过大，又遇到GROUP BY或ORDER BY大结果集，MySQL会把临时表建在内存里，撑爆后才退到磁盘；但撑的过程已经让系统喘不过气。
-
innodb_buffer_pool_size建议不超过物理内存的70%，且必须预留至少1GB给OS和其他进程 - 避免全局设置过大的线程级缓冲（如
read_buffer_size> 2M），改用会话级动态调整 - 用
SHOW GLOBAL STATUS LIKE 'Created_tmp%'观察内存临时表创建频次，高了就要收紧tmp_table_size
如何从错误日志里排除OOM干扰
MySQL错误日志里出现Aborted connection、Got an error reading communication packets或者干脆日志戛然而止，**不能直接等同于SQL出错**。这些很可能是连接被中断的“结果”，而非“原因”。真正的原因藏在系统层。
关键动作是交叉验证：查完dmesg确认OOM后，再回头检查MySQL慢查询日志（如果开着）和SHOW PROCESSLIST历史快照（如有监控留存）。你会发现出事前往往有长事务、全表扫描或未加索引的LIKE '%xxx%'查询在后台狂跑。
- 启用
log_error_verbosity = 3能让错误日志多记一点上下文，但救不了OOM本身 -
log_output = 'TABLE'+slow_query_log = ON可减少I/O抖动，但前提是mysqld还活着能写 - 真正有效的“日志”其实是
/proc/<pid>/status</pid>里的VmRSS和VmData，需配合监控工具定时采集
临时保命与长期水位控制
刚被OOM搞崩，重启MySQL只是开始。立刻做两件事：降配+限流。别想着“先恢复业务再说”，下一次崩溃可能就在五分钟内。
临时手段很简单：改小innodb_buffer_pool_size（比如从16G砍到8G），加上max_connections = 100硬限制，并用systemd设置MemoryLimit（如果跑在systemd下）。这不是最优解，但能让你有时间看监控、查慢SQL、加索引。
- 用
mysqltuner.pl脚本只能给建议，它不会告诉你当前VmRSS已到15.8G —— 得自己看ps aux --sort=-%mem | head -5 - 容器环境务必设置
--memory和--memory-reservation，否则cgroup对OOM Killer无效 - 最常被忽略的一点：
swappiness=1（不是0！）能让内核更倾向回收page cache而非杀进程，对MySQL友好得多
OOM不是MySQL的bug，是资源预算和负载节奏没对齐。查日志只是确认死因，活下来靠的是提前知道它哪口气最喘。
