MySQL 8.0 OOM自动重启主因是innodb_buffer_pool_size越界与log_bin开启双重问题；需查dmesg确认OOM实锤、盯free -h的available值、同步调整chunk_size与instances并删除ib_logfile*和binlog文件后重启验证。
MySQL 8.0 的 OOM 自动重启，90% 不是内存碎片，而是 innodb_buffer_pool_size 配置越界 + log_bin 开着双重踩坑。所谓“内存碎片”在 InnoDB 中几乎不构成 OOM 主因——Buffer Pool 内部用 LRU 和 chunk 管理，不会像 malloc 那样产生不可回收碎片；真正压垮系统的，是配置值超出物理内存余量、或 binlog 持续写入触发额外缓冲与刷盘压力。
查清是不是真被 OOM Killer 杀了
别猜，直接看内核日志：
- 运行
dmesg | grep -i "killed process.*mysqld"—— 出现即实锤 OOM - 运行
grep -i "out of memory" /var/log/messages（或/var/log/syslog）确认时间点和当时available内存余量 - 运行
free -h，盯住available列，不是free；若长期
调 innodb_buffer_pool_size 必须守三硬约束
改这个值不是填个数字就完事，MySQL 8.0 会校验合法性，填错直接启动失败：
- 必须是
innodb_buffer_pool_chunk_size×innodb_buffer_pool_instances的整数倍（默认 chunk=128M, instances=8 → 最小合法值=1G） - 不能高于热数据总量 × 1.2：用
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','performance_schema','information_schema');算出后留余量 - 必须给 OS 留 ≥1.8GB：2GB 机器设 768M，4GB 设 1G，8GB+ 才考虑 2G–4G；设完再跑
free -h确认 available ≥1.8G
关 log_bin 是单机环境最省事的减负操作
宝塔面板部署的 MySQL 8.0，除非你在做主从或需要闪回，否则 log_bin 开着纯属负担：
- 执行
mysql -e "SHOW VARIABLES LIKE 'log_bin';"，返回ON就得关 - 在
/www/server/panel/vhost/mysql/my.cnf（或宝塔 MySQL 配置文件路径）里加一行：skip-log-bin - 删掉旧 binlog 文件：
rm -f /www/server/data/mysql-bin.*和/www/server/data/ib_logfile* - 重启前务必删
ib_logfile0和ib_logfile1，否则启动卡在InnoDB: Error: log file ib_logfile0 is of different size
长连接累积才是隐蔽的内存推手
即使 Buffer Pool 和 binlog 都调好了，max_connections 高 + 长连接不释放，照样 OOM：
- 每个连接固定占用约 256KB（由
thread_stack控制），1000 连接就是 256MB，还不算临时表、排序缓存等动态内存 - 查当前活跃连接：
SHOW STATUS LIKE 'Threads_connected';，持续 >200 就该警惕 - 5.7+ 版本可用
mysql_reset_connection重置单个连接内存状态，比断连轻量；应用层应设空闲超时（如wait_timeout=300）
真正麻烦的从来不是参数本身，而是多个约束条件交叉生效——比如你把 innodb_buffer_pool_size 改成 1.2G，却没同步调 innodb_buffer_pool_instances，MySQL 会静默向下取整到 1G，你以为调小了，其实没变；又或者删了 binlog 却忘了删 ib_logfile*，结果 mysqld 根本起不来。每一步都得验证落地效果，而不是只改配置就以为万事大吉。
