mysql 8.0 启动报错 unknown variable 'query_cache_type'，是因为该变量已被源码级彻底删除，必须物理删除配置文件中所有以 query_cache_ 开头的行（含注释），否则服务无法启动。
MySQL 8.0 启动报错 Unknown variable 'query_cache_type'
这是最典型的跨版本升级失败信号，不是配置写错了，是变量本身在源码里被删干净了。MySQL 8.0+ 启动时遇到任何 query_cache_* 配置项都会直接退出，并抛出类似 Unknown variable 'query_cache_type' 的错误。
必须在重启前完成清理：
- 打开实际生效的配置文件（宝塔用户是
/www/server/mysql/etc/my.cnf，Docker 用户检查挂载到/etc/mysql/conf.d/下的文件） - 在
[mysqld]段内，删掉所有以query_cache_开头的行——包括query_cache_type、query_cache_size、query_cache_limit，一个都不能留 - 不要用
#注释，注释仍会触发解析，必须物理删除 - 检查是否有多个配置文件被加载（如
/etc/mysql/mysql.conf.d/下的额外 .cnf），一并排查
5.7 升级到 8.0 后 slow_query_log 不生效？检查 log_output 和 slow_query_log_format
MySQL 8.0 默认关闭慢查询日志，且日志格式逻辑变了：旧版纯文本 + mysqldumpslow 分析的方式大概率失效。
正确启用方式是改用表输出，避免文件解析问题：
- 在
[mysqld]中设置：slow_query_log = ON、long_query_time = 1.0（注意单位是秒，支持小数） - 强制指定输出目标：
log_output = 'TABLE'（不是'FILE'） - 无需设置
slow_query_log_format，写入mysql.slow_log表后，字段含sql_text、query_time、rows_examined等，可直接 SQL 查询分析 - 云厂商 RDS 常禁用
SET GLOBAL slow_query_log = ON，必须改配置 + 重启
升级后性能反而下降？先查 ANALYZE TABLE 和 optimizer_switch
缓存没了不是性能下降的主因，而是优化器“失忆”了：INNODB_TABLESTATS 里的统计信息还停在 5.7 时代，导致执行计划严重误判。
立即执行以下动作：
- 对所有慢查询涉及的表运行：
ANALYZE TABLE your_table;（不是单张，是全部高频表） - 确认是否启用了持久化统计：
SELECT @@innodb_stats_persistent;，应为ON；若为OFF，设SET PERSIST innodb_stats_persistent = ON; - 对比升级前后
SELECT @@optimizer_switch;输出，重点关注mrr=off、index_merge=on这类默认变更项；临时验证可用SET SESSION optimizer_switch='mrr=on'; - 若
EXPLAIN出现Using intersect()，大概率是index_merge在干扰，可先关掉
innodb_buffer_pool_size 调大后 QPS 还上不去？检查 buffer_pool_instances
把原来给 query cache 的内存转给 innodb_buffer_pool_size 是对的，但只调大小不够——InnoDB 缓冲池内部争用没解，性能提升会被抵消。
关键参数是 innodb_buffer_pool_instances：
- 该值应 ≥ 8（尤其当
innodb_buffer_pool_size > 4G时），否则单个 mutex 锁会成为瓶颈 - 计算公式：实例数 = 缓冲池总大小（MB）÷ 1024，向上取整，上限 64
- 例如设了
innodb_buffer_pool_size = 8G，就应配innodb_buffer_pool_instances = 8 - 改完必须重启，且要观察
SHOW STATUS LIKE 'Innodb_buffer_pool_wait_free';是否显著下降
别以为删掉 query_cache_* 就算升级完成。真正卡住性能的，往往是那些没被显式报错、却默默拖慢每条查询的隐性配置偏差——比如 optimizer_switch 里一个 =off 的开关，或 buffer_pool_instances 没随内存同比例放大。
