先查dmesg确认OOM Killer杀进程，再调innodb_buffer_pool_size≤物理内存50%、关buffer_pool_dump/load、删旧日志文件并重启MySQL。
宝塔面板MySQL偶尔自动崩溃，大概率是系统触发OOM Killer强制杀掉mysqld进程，不是MySQL自己出错。开启Swap并调低oom_score_adj能缓解，但不能替代内存参数优化。
怎么确认真是OOM Killer干的？
别猜，直接查内核日志：sudo dmesg -T | grep -i "killed process" | grep mysqld。如果输出里有total-vm、anon-rss数值，且时间点和MySQL停止吻合，就是它。这时候free -h看到的available值往往已逼近0，但free列还剩一点——那是假象，Linux内核已无页可分配。
Swap不是万能解药，但2GB以下内存必须开
OVZ架构机器不支持Swap，跳过这步；其余情况建议按物理内存1.5倍设（如1GB内存配1.5G Swap），上限不超过4G。关键操作顺序不能错：
- 先执行
swapon --show确认没启用 - 用
fallocate -l 2G /swapfile创建（别用dd，太慢） chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile- 追加
/swapfile none swap sw 0 0到/etc/fstab，否则重启失效
注意：/www/swap是宝塔工具箱默认路径，但手动建Swap更可控；Swap文件位置不影响MySQL，只影响系统内存回退能力。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
为什么调oom_score_adj效果有限？
给mysqld进程设更低的oom_score_adj（比如-500），只是让它比Nginx、PHP-FPM更晚被杀——但当系统真缺内存时，它迟早还是第一个躺平。真正该做的是：
- 进宝塔→MySQL→配置修改，把
innodb_buffer_pool_size压到物理内存的50%以内（2GB机器设1G，别写1024M，MySQL 8.0+对单位敏感） - 关掉
innodb_buffer_pool_dump_at_shutdown = OFF和innodb_buffer_pool_load_at_startup = OFF，这两个默认开启的功能在小内存机器上启动瞬间吃光可用内存 - 删掉旧日志文件：
rm /www/server/mysql/data/ib_logfile*，再重启MySQL，否则innodb_log_file_size调大后无法生效
Swap和oom_score_adj是兜底手段，核心矛盾永远在innodb_buffer_pool_size是否超支、是否匹配你的free -h中available值——这个值才是MySQL能安全使用的上限，不是总内存也不是free列。
