MySQL 8.0 已彻底移除查询缓存，query_cache_size等参数配置即报错；性能优化应聚焦innodb_buffer_pool_size、索引设计及I/O调度，而非无效缓存配置。
MySQL 8.0 完全没有查询缓存，别在 my.cnf 里写 query_cache_size —— 一加就启动失败，日志明确报 Unknown variable 'query_cache_size'。
确认 MySQL 版本再动手
宝塔面板里点【软件商店】→ 找到 MySQL → 看安装详情，或终端执行：mysql --version。只要显示 8.0.x，就彻底放弃查询缓存相关配置。网上大量“调优教程”混用 5.7 和 8.0 参数，直接照搬会导致 mysqld 启动卡死。你看到的“缓存命中率低”，在 8.0 里根本不是缓存问题，而是 innodb_buffer_pool_size 没设对、或者 SQL 写法触发了全表扫描。
8.0 的 innodb_buffer_pool_size 要比 5.7 更谨慎
8.0 对内存管理更激进，innodb_buffer_pool_size 设高了容易触发 OOM killer 杀掉 mysqld 进程；设低了又因元数据缓存（data dictionary cache）、DDL 日志缓存等新模块抢内存，导致实际可用缓冲更少。
- 查当前总数据量：
du -sh /www/server/mysql/data/* | grep -E "(ibdata|mysql)"，比如结果是 3.2G - 保守起步值 = 数据量 × 1.5 ≈ 4.8G，但物理内存若为 8G，
innodb_buffer_pool_size最多设5G（留至少 2G 给系统、宝塔、SSH） - 必须写成整数单位：
5G或5120M都行，但别写4800M—— 8.0 要求按 1MB 对齐，否则启动时静默忽略 - 验证是否生效：
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"，值必须和你写的完全一致
5.7 和 8.0 的线程级缓冲区不能通用套用
sort_buffer_size、join_buffer_size 这类参数在 8.0 中默认值已下调（例如 sort_buffer_size 从 5.7 的 256K 降为 128K），因为 8.0 优化器更倾向走索引排序而非内存排序。盲目沿用 5.7 的“加大”思路，反而会放大并发内存压力。
- 轻量应用（如 WordPress、小型后台）：保持 8.0 默认值即可，
sort_buffer_size = 128K、join_buffer_size = 256K - 真有大排序需求（如报表导出 ORDER BY 百万行）：先看状态值：
SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';，持续上升再微调，每次只加 64K - 绝对不要设
join_buffer_size = 4M—— 100 并发连接就能吃掉 400MB，8.0 下更容易被系统 kill - 这些参数必须放在
[mysqld]段下，且不能和[client]混写，否则加载无效
重启后必须立刻验证配置文件真实加载路径
宝塔改完 /www/server/mysql/my.cnf，不代表 mysqld 就读它。MySQL 启动时按固定顺序找配置文件：/etc/my.cnf → /etc/mysql/my.cnf → /www/server/mysql/etc/my.cnf → /www/server/mysql/my.cnf，**第一个存在且语法正确的就停**。很多用户改了宝塔界面里的文件，结果被 /etc/my.cnf 覆盖了。
- 查实际加载路径：
mysql -Nse "SELECT @@global.config_file;"（8.0+ 支持），或看错误日志：grep "my.cnf" /www/server/mysql/data/*.err - 校验语法是否合法：
mysqld --defaults-file=/www/server/mysql/my.cnf --verbose --help 2>/dev/null | head -5，没报错才说明能正常解析 - 重启必须用宝塔【重启 MySQL】按钮，或命令
service mysqld restart，reload不刷新全局变量
最常被忽略的是：8.0 的性能拐点不在缓冲区大小，而在 I/O 调度和脏页刷新策略。如果磁盘 IOPS 上不去，innodb_buffer_pool_size 再大也白搭 —— 先确认你用的是 SSD，再谈调参。
