MySQL内存溢出本质是系统oom-killer杀掉mysqld进程，错误日志不记录“内存溢出”或“OOM”，仅可能留有模糊的Cannot allocate memory或静默崩溃；真正证据在dmesg中“Killed process mysqld”及/var/log/messages里的oom_kill记录。
MySQL错误日志里根本不会写“内存溢出”四个字
查 mysqld.err 搜索 Out of memory 或 OOM，大概率空手而归。MySQL 自身不抛 OutOfMemoryError，也不会记录“内存溢出”——它只会在 malloc 失败时记一条模糊的 Cannot allocate memory，甚至直接静默终止。此时进程早已被系统 oom-killer 杀掉，错误日志可能停在崩溃前几秒，内容完全无关。
真正该盯的是 dmesg 里的 “Killed process mysqld”
这是 OOM 的铁证，不是猜测。执行以下命令确认：
-
dmesg -T | grep -i "killed process"—— 输出含mysqld和时间戳，且时间与崩溃吻合，就是它 -
grep -i "oom_kill\|badness" /var/log/messages（或/var/log/syslog）—— 补充交叉验证 -
ps aux --sort=-%mem | head -5—— 查备份/高峰时段是否有其他进程（如 Python 脚本、Java agent）同步吃内存，挤占mysqld可用空间
错误日志末尾的 Crash Recovery 不是原因，而是结果
InnoDB: Starting crash recovery 这行只是 MySQL 重启后做的善后动作，不能告诉你为什么崩。真正诱因藏在它前面 10～20 行的 ERROR 或 FATAL 日志里：
- 用
tail -n 200 /var/lib/mysql/hostname.err看末尾（路径以show variables like '%log_error%'为准） - 用
grep -B 5 -A 5 'InnoDB: Starting crash recovery' /var/lib/mysql/hostname.err拉出上下文，再人工往回翻 - 若日志轮转过，别漏查
error.log.1.gz：zcat error.log.1.gz | grep -i "error\|fatal" | tail -n 10
重点关注这些关键词：Killed process mysqld（系统杀的）、InnoDB: Assertion failure（代码缺陷或页损坏）、Operating system error number 2（文件丢失或权限问题）。
备份或高并发场景下，哪些配置最容易叠buff式触发OOM
不是单个参数超限，而是多个连接级缓冲叠加后总内存失控：
-
innodb_buffer_pool_size：专用库可设物理内存 50%–80%，但必须预留 ≥2GB 给 OS；混合部署要先减去 Nginx、Python 等常驻内存 -
sort_buffer_size、join_buffer_size、read_buffer_size：每个连接独占，设 4M + 500 连接 = 6GB，不是理论值，是真实占用 -
tmp_table_size和max_heap_table_size：取小值，设 512M + 复杂GROUP BY→ 单查询几百 MB -
performance_schema：默认开启，高并发下自身开销可达 1–2GB；非深度诊断需求可设performance_schema=OFF（需重启）
最危险的组合是：大表导出 + 高 max_connections + 全局缓冲偏大 + performance_schema 开启。这种时候看错误日志没用，得先跑 dmesg，再算内存账。
