mysql 8.0 实际加载的配置文件路径需通过 ps aux | grep mysqld 查启动参数确认，默认顺序为 /etc/my.cnf → /etc/mysql/my.cnf → /usr/etc/my.cnf → ~/.my.cnf，宝塔写入的 /www/server/mysql/my.cnf 不在此列，故常不生效；务必删/重命名冲突的 /etc/my.cnf 并用 systemctl restart mysqld 重启验证。
确认 MySQL 8.0 实际加载的 my.cnf 文件路径
宝塔界面修改配置后没生效，90% 是因为 MySQL 没读你改的那个文件。MySQL 8.0 启动时按固定顺序查找配置文件：/etc/my.cnf → /etc/mysql/my.cnf → /usr/etc/my.cnf → ~/.my.cnf，而宝塔默认写入的是 /www/server/mysql/my.cnf——这个路径不在默认搜索列表里，除非显式指定。
实操建议：
- 查 MySQL 当前实际加载的配置：
mysql -Nse "SELECT @@global.config_file"（8.0+ 支持）；如果报错或返回空，说明它没走 config_file 变量，得看启动命令 - 更可靠的方式是查进程参数：
ps aux | grep mysqld | grep -o '\-\-defaults-file=[^ ]*'，若没出现，说明用的是默认路径，此时/etc/my.cnf若存在，就会覆盖宝塔改的/www/server/mysql/my.cnf - 最稳妥做法：删掉或重命名
/etc/my.cnf（如有），然后在宝塔「数据库 → MySQL管理 → 配置修改」里编辑/www/server/mysql/my.cnf，并确保该文件顶部有[mysqld]段落 - 改完别急着重启，先校验语法：
mysqld --defaults-file=/www/server/mysql/my.cnf --verbose --help 2>/dev/null | head -5，不报错才继续
只调 innodb_buffer_pool_size 就能解决 80% 的高内存问题
MySQL 8.0 默认启用 InnoDB，且 innodb_buffer_pool_size 是它吃内存的绝对大头。其他参数如 sort_buffer_size 是线程级的，影响小得多；而 query_cache_size 在 8.0 已被彻底移除，写进去也无效，还可能引发警告。
实操建议：
- 先看真实数据量：
du -sh /www/server/mysql/data/* | grep -E "(ibdata|[^.])$"，把各库目录加起来，再加ibdata1（如果没开innodb_file_per_table） - 保守设法：取总数据量 × 1.5，但上限不超过物理内存的 70%，例如 4GB 内存服务器，
innodb_buffer_pool_size = 1G比设 2G 更稳 - 单位直接写
1G或512M，别写536870912这种字节值——易错且难读 - 设太高会触发 OOM Killer 杀 mysqld 进程，日志里搜
Out of memory: Kill process mysqld就能确认
max_connections 和线程缓冲区必须同步下调
MySQL 8.0 默认 max_connections = 151，每个连接还会分配 sort_buffer_size、join_buffer_size 等。哪怕只开 50 个连接，若这些 buffer 还是默认的 2MB/4MB，瞬间就吃掉几百 MB。
实操建议：
- 先查当前峰值连接数：
SHOW GLOBAL STATUS LIKE 'Threads_connected';和SHOW GLOBAL STATUS LIKE 'Threads_created';，观察一天内最高值 - 设
max_connections = 100（够中小型 WordPress/Typecho 站点用），再配一组保守 buffer：sort_buffer_size = 256K、join_buffer_size = 256K、read_buffer_size = 128K - 注意：这些 buffer 是“每个连接都分配”，不是全局共享，所以值要小，且必须写在
[mysqld]段落里，不能漏掉 - 改完重启后验证：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';和SHOW VARIABLES LIKE 'max_connections';，确认值已更新
重启必须用 systemctl 或宝塔「重启」，不能 reload
innodb_buffer_pool_size 这类参数属于“静态变量”，MySQL 启动时读取一次就固化在内存里，SIGHUP（即 systemctl reload mysqld 或宝塔「重载配置」）完全不生效，只会让你误以为改成功了。
实操建议：
- 宝塔界面点【重启 MySQL】是最稳妥的，它本质是
systemctl restart mysqld - 如果面板卡住或失败，手动执行：
systemctl restart mysqld，然后立刻检查：systemctl status mysqld和journalctl -u mysqld -n 20 --no-pager - 特别注意：若重启后 MySQL 启不来，大概率是
innodb_buffer_pool_size设超了可用内存，看日志里是否有InnoDB: Cannot allocate memory for the buffer pool - 上线前务必观察 10 分钟：
free -h看available是否稳定在 500MB 以上，ps aux --sort=-%mem | head -3看 mysqld RSS 是否回落到预期范围
真正容易翻车的地方，不是参数写错，而是改完没确认 MySQL 到底读的是哪个文件、也没验证变量是否真刷新了。很多人的配置明明改对了，却因 /etc/my.cnf 存在或重启方式不对，全程在改“空气”。
