MySQL被OOM Killer杀死的典型迹象是宝塔显示“已停止”但systemctl可立即启动，几小时后又静默退出；验证需运行dmesg -T | grep -i "killed process"，若输出含"Killed process xxx (mysqld)"即可确认。
MySQL 被系统 kill -9 的典型迹象
宝塔面板里 MySQL 显示“已停止”，但手动 systemctl start mysqld 又能立刻起来，几小时后又静默退出——这大概率不是 MySQL 自己崩了，而是被 Linux 内核的 OOM Killer 主动干掉的。
查证方法很简单：运行 dmesg -T | grep -i "killed process"。如果输出里出现类似 Killed process 12345 (mysqld) 的记录，基本坐实是内存不足触发了 OOM Kill。
- OOM Killer 不会写日志到
/var/log/mysqld.log或宝塔日志里，只留在内核环形缓冲区（dmesg） - 宝塔服务状态页显示“未运行”，但
ps aux | grep mysqld找不到进程，也无崩溃堆栈，就是典型 OOM 表现 - 不要先改 MySQL 配置，得先确认是不是真被 kill —— 很多人花半天调
innodb_buffer_pool_size，结果根本没触发过 MySQL 层面的内存报错
查清 MySQL 实际内存占用和系统水位
MySQL 声称的内存用量（比如配置里写的 innodb_buffer_pool_size）只是预估，真实 RSS 占用可能高得多，尤其在连接数多、临时表/排序多时。
用这两条命令交叉验证：
-
ps -o pid,user,%mem,rss,comm -C mysqld看当前 RSS 占用（单位 KB），注意是rss不是%mem -
free -h和cat /proc/meminfo | grep -E "MemAvailable|MemTotal"看系统可用内存是否长期低于 512MB - 配合
top -p $(pgrep mysqld)观察 RES 列波动，如果持续逼近总内存 80% 以上，OOM 风险极高
注意：小内存 VPS（比如 1GB）跑宝塔 + MySQL + Nginx + PHP-FPM，默认配置很容易把内存吃光。宝塔的“推荐配置”对低配机器不适用。
快速止血：限制 MySQL 内存上限
别急着调优，先让服务稳住。最直接有效的是用 systemd 强制限制 MySQL 进程内存使用上限，防止它吃光所有内存后被杀。
执行以下操作：
-
sudo systemctl edit mysqld（或mariadb，看实际服务名） - 填入：
[Service] MemoryLimit=768M
sudo systemctl daemon-reload && sudo systemctl restart mysqld
这个 MemoryLimit 是 cgroup v2 的硬限制，比 MySQL 自身配置更可靠。设为总内存的 60%～70% 比较安全（例如 1GB 机器设 768M）。设太低会导致 MySQL 报 Out of memory 错误，但至少不会拖垮整个系统。
长期要调的几个关键 MySQL 参数
限制只是兜底，真正要减负得精简 MySQL 的内存胃口。重点盯这几个参数，它们对 RSS 影响最大：
-
innodb_buffer_pool_size：设为物理内存的 40%～50%，1GB 机器建议 384M～448M，别照宝塔默认的 512M -
max_connections：宝塔默认 500，小内存机设成 50～100 更现实；连接数每增 1，线程栈+缓存就多占几 MB -
tmp_table_size和max_heap_table_size：都设成 32M 或 64M，防大查询建巨型内存临时表 - 关掉不用的引擎：
skip-innodb不要加（除非你真不用 InnoDB），但可以skip-partition、skip-ndbcluster
改完记得 mysqladmin shutdown 再 systemctl start mysqld，避免热加载不生效。观察 24 小时 ps 输出的 RSS 是否稳定在限值内。
OOM Kill 看似是 MySQL 的问题，其实是资源分配没对齐——系统没给足，MySQL 又不懂收敛，最后 kernel 只能动手。调参前务必先看 dmesg，不然所有优化都是朝空气开枪。
