MySQL内存飙高主因是innodb_buffer_pool_size默认按总内存50%~80%分配，小内存VPS易OOM；应据内存大小设为512M（2G）、1G（4G），并调低PHP子进程数、禁用冗余扩展、清理日志。
MySQL内存占用突然飙高，mysqld吃掉70%以上内存怎么办
宝塔面板本身不直接控制MySQL内存，真正“抢内存”的是mysqld进程——它默认按服务器总内存的50%~80%预分配缓冲区，尤其在2G~4G小内存VPS上极易OOM。这不是配置错误，而是MySQL 5.7+默认行为与小内存环境严重错配。
实操建议：
- 先确认真实内存压力：
free -h看available值，不是free；再用ps aux --sort=-%mem | head -5锁定mysqld实际RSS占用 - 别直接改
/www/server/mysql/my.cnf里所有innodb_buffer_pool_size相关项——只调这一项就对小内存机器足够有效 - 2G内存VPS建议设为
512M，4G设为1G，8G以上才考虑保留默认的128M起步动态调整 - 改完必须重启
mysqld：systemctl restart mysqld（宝塔界面点“重启”有时不生效）
为什么改了innodb_buffer_pool_size后网站变慢或报错
这个值不是越小越安全，也不是越大越好。它本质是InnoDB缓存热数据的“工作台”，设太小会导致频繁磁盘读，尤其wp_options、typecho_contents这类高频表会明显卡顿；设太大又挤占系统缓存和PHP内存，触发Linux OOM Killer杀进程。
常见错误现象：
- WordPress后台打开慢，
SELECT option_value FROM wp_options WHERE option_name = 'cron'查得特别久 - 宝塔面板首页显示“MySQL未运行”，但
systemctl status mysqld显示active，其实是启动时因内存不足被系统kill -
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'——根本不是socket路径问题，是进程没起来
关键判断：如果journalctl -u mysqld | grep -i "killed process"输出含Out of memory，就是内存分配冲突了。
宝塔自带的“数据库优化”工具到底能不能信
宝塔6.x/7.x的“数据库优化”按钮，本质是执行一套固定SQL（如OPTIMIZE TABLE）+ 写死的my.cnf模板覆盖，对内存无实质调节能力。它甚至可能把key_buffer_size（MyISAM用）设成128M，而你的库全用InnoDB，纯属浪费。
实操建议：
- 关掉宝塔自动优化：面板 → 数据库 → 设置 → 取消勾选“定期优化数据库”
- 手动检查引擎类型：
SELECT table_schema,table_name,engine FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys'); - 若全是
InnoDB，就把key_buffer_size降到16M，query_cache_type设为0（MySQL 8.0已移除，5.7务必关） - 避免使用宝塔“一键修复”功能——它可能重置你刚调好的
innodb_buffer_pool_size
PHP-FPM和MySQL抢内存时，优先保谁
小内存服务器上，php-fpm和mysqld是内存双雄。宝塔默认给PHP开20个子进程，每个平均占20MB，光PHP就吃掉400MB，再加MySQL的1G，系统直接喘不过气。
更合理的分工：
- 先压低MySQL：按前述方法锁死
innodb_buffer_pool_size，这是内存大头 - 再收紧PHP：面板 → PHP设置 → 进程管理 → 把
max_children从20改成8（2G内存）或12（4G），pm.max_requests保持1000防内存泄漏 - 禁用不用的PHP扩展：
redis、mongodb这些模块不启用时也占内存，面板 → PHP设置 → 禁用扩展 - 别碰
swap：宝塔建的swap文件在/www/swap，开启后MySQL响应延迟飙升，不如直接调低buffer
最常被忽略的一点：宝塔日志轮转（/www/wwwlogs）默认不限大小，跑几个月能吃掉几个G，记得在面板 → 安全 → 日志清理里设成“保留30天”。
