我遇到过很多次这种报错每次帮别人排查的时候第一反应基本都是这哥们儿又升级MySQL版本了而且没清理老配置文件。Unknown system variable query_cache_size这个问题说白了就是MySQL 8.0版本把查询缓存Query Cache整个功能给删掉了但你的配置文件里还留着老版本的参数设置启动时MySQL根本不认识这些参数自然直接报错退出。今天我把这个问题的来龙去脉、处理方式和避坑经验一次性说清楚。1. 先说清楚这个报错到底是怎么来的1.1 一段前尘往事查询缓存的兴衰MySQL的查询缓存功能从很早的版本就存在了它的核心思想特别朴素如果连续执行两条一模一样的SELECT语句而且涉及的表数据在这期间没有任何变化第二次就可以直接把第一次缓存好的结果集返回省去重新解析SQL、扫描索引、读数据页的整个过程。在MySQL 5.1到5.7这个时代这个概念听起来很诱人尤其对于读多写少、数据基本不怎么变动的业务场景打开query_cache_type1配置一个合适的query_cache_size确实能在某些场景下带来明显的性能提升。但查询缓存的实现有一个致命短板失效太频繁。只要表上发生了任何写操作INSERT、UPDATE、DELETE哪怕只影响了一行这张表的所有查询缓存全部作废。也就是说在写入稍微频繁一点的业务里缓存刚缓存好一批结果还没来得及命中几次就被一次写操作给清空了吃力不讨好反而因为维护缓存还要额外消耗CPU和锁资源。所以在MySQL 8.0正式发布时官方直接砍掉了这个模块query_cache_type、query_cache_size、query_cache_limit这一整批参数全部移除连带着SQL_CACHE、SQL_NO_CACHE这两个SQL提示符也没了。1.2 报错的两个典型触发场景第一个场景是启动服务直接失败。这种情况最常见于把MySQL从5.7升级到8.0或者新安装的8.0实例使用了从5.7拷贝过来的my.cnf配置文件。只要文件里有类似下面这些参数MySQL 8.0在初始化阶段就会报错退出query_cache_type1 query_cache_size67108864 query_cache_limit1048576第二个场景是执行SQL语句时触发。一些老版本的ORM框架或者早期封装的数据库中间件内部逻辑为了“优化性能”会主动执行SET SESSION query_cache_type ON;这类语句在8.0上同样会得到一模一样的报错。注意你在网上搜索这个报错时能看到很多文章让你“把MySQL升级到5.7.20以上”这种说法不仅过时而且有害。5.7.20只是修复了查询缓存相关的内存分配Bug从未等于“支持Oracle的付费功能”。8.0才是彻底移除必须用完全不同的思路来解决。2. 最快的解决办法让配置和版本对齐2.1 找出并清理配置文件里的残留参数排查的第一步是找到MySQL当前实际读取的配置文件。注意Linux系统中存在多个候选位置MySQL会按顺序读取后读取的会覆盖先读取的同名参数。最常见的路径包括/etc/my.cnf/etc/mysql/my.cnf/etc/mysql/mysql.conf.d/mysqld.cnfUbuntu/Debian常见$MYSQL_HOME/my.cnf编译安装时指定的basedir目录下的my.cnf保险起见用一个命令把实际生效的配置路径打印出来mysqld --verbose --help | grep -A 1 Default options输出结果会显示“Default options are read from the following files in the given order”把每个路径都检查一遍用grep -n query_cache找到带query_cache字样的行直接注释或删除。我的习惯是先用grep定位确认无误后再统一编辑。比如grep -rn query_cache /etc/my.cnf /etc/mysql/找到之后把这些行整行删掉或者用#注释掉二选一。有些同学舍不得删想注释掉留给以后参考完全可以注释不影响启动。2.2 处理其他相关的“老参数”除了query_cache_size8.0里一起被移除的查询缓存参数还包括参数名作用8.0中的状态query_cache_type查询缓存开关已移除query_cache_size缓存总内存大小已移除query_cache_limit单条结果集缓存上限已移除query_cache_min_res_unit缓存块最小单位已移除query_cache_wlock_invalidate写锁期间是否失效缓存已移除另外还有两个经常和它一起打包出现的老参数也值得检查一遍key_buffer_sizeMyISAM索引缓存8.0中仅对MyISAM表仍有效不影响InnoDB和innodb_buffer_pool_size这个在8.0中仍然有效且是核心参数千万别删。清理完配置文件后重启MySQL服务systemctl restart mysqld或者service mysql restart启动成功后登录进入MySQL执行SHOW VARIABLES LIKE query_cache%;返回一个空结果集就说明彻底干净了。2.3 如果报错来自应用端SQL语句如果服务能正常启动但某个应用连接MySQL时报Unknown system variable query_cache_size说明不是配置文件的问题而是应用在连接初始化阶段执行了设置查询缓存参数的SQL。排查思路是看两个方向第一应用的数据库连接池配置。以Java的HikariCP、Druid为例有些老项目的connection-init-sql配置里写入了SET SESSION query_cache_typeON;这种初始化语句。在MySQL 8.0中这属于非法SQL直接导致连接初始化失败。解决办法是去掉这段初始化SQL。第二ORM框架或中间件版本太旧。比如某些老版本的MyBatis、Hibernate方言配置中带了query_cache相关内容或者TTL Cache中间件中配置了这类语句升级到适配MySQL 8.0的版本即可。判断原则很简单启动都失败先查my.cnf启动正常但运行中报错先查应用和中间件。两条线不要搞反。3. 从5.7迁移到8.0时的系统性配置清理3.1 MySQL 8.0的参数兼容性全局变化如果你正在规划5.7到8.0的升级query_cache相关参数只是冰山一角。8.0对参数体系做了大范围的调优和精简涉及字符集、认证插件、排序规则、系统表结构等方方面面。这里列一个常用清单升级前对照检查老参数/配置项5.7状态8.0状态处理建议query_cache_*可用已移除删除配置改用业务层缓存或优化SQLsql_mode默认宽松默认严格ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES等升级前先用5.7测试严格模式兼容性default_authentication_pluginmysql_native_passwordcaching_sha2_password老客户端需要升级驱动default_charsetutf8mb3即utf8utf8mb4需显式指定或接受默认information_schema_stats_expiry无86400默认统计信息过期导致执行计划漂移可调整innodb_file_formatAntelopeBarracuda默认已自动切换无需处理log_bin默认关闭默认关闭但binlog格式默认ROW确认备份恢复策略explicit_defaults_for_timestamp有默认值与5.7一致行为更规范需注意TIMESTAMP字段默认值行为差异这个表不是让你全背下来而是提示你升级不是简单地跑一遍mysql_upgrade就完事至少要把配置逐项检查一遍。3.2 拿一台测试机做“试运行”别直接在线上库执行升级这个坑我踩过一次之后再也不敢偷懒。第一步准备一台与线上配置接近的虚拟机或容器安装与现网大版本一致的5.7导出一份线上数据做恢复测试。第二步在测试机上停止MySQL 5.7备份老数据目录datadir把二进制文件替换成8.0启动时先不加载老配置文件使用mysqld --initialize初始化一个新的数据目录再把旧数据通过逻辑备份方式导入。导入完成后打开一个隐藏配置文件的副本逐个参数测试看哪些参数导致MySQL拒绝启动。第三步全程观察错误日志/var/log/mysql/error.log遇到Unknown system variable就删掉对应行遇到Unknown storage engine就检查引擎兼容性。实测下来把5.7换成8.0并全量导入数据大约需要按顺序处理以下几类问题查询缓存族参数本次主题字符集相关的character_set_server差异旧版mysql_native_password认证插件导致的客户端连接失败触发器、函数、存储过程中的SQL模式差异处理完一轮之后再把测试机上最终版本干净且可用的配置文件作为线上配置的基准而不是直接拿老文件改来改去。3.3 迁移后性能不仅没变差反而可能更快很多人以为移除查询缓存会导致读性能大幅下降但实际上8.0用更底层的机制换回了更稳定的整体表现。InnoDB缓冲池innodb_buffer_pool_size把热数据页放在内存中查询时直接读内存页本身就是一个天然的“页级缓存”比查询缓存的结果集序列化存储更高效。而且8.0的优化器更强了基于代价的索引选择配合直方图、倒序索引等新特性很多原本依赖查询缓存“糊弄性能”的场景在主键索引或二级索引合理的情况下根本不需要额外缓存层。迁移之后我的实测经验是去掉查询缓存反而减少了全局锁竞争在写入频率较高的业务里整体吞吐反而更稳定了。4. 如果你真的需要缓存三个替代方案4.1 应用层缓存最推荐查询缓存没了业务对“热点查询”的缓存需求并没有消失。最靠谱的方案是把缓存放到应用层用Redis或Memcached来承载。考虑一个商品信息查询的场景原本靠MySQL查询缓存扛住“同一个商品详情页被反复查询”的热点流量现在可以在应用服务里加一层Redis1. 请求进来先查RedisKey设计为 product:detail:{productId} 2. Redis命中直接返回不访问MySQL 3. Redis未命中查询MySQL把结果序列化写入Redis设置过期时间比如10分钟 4. 数据发生变更时主动更新Redis里的对应Key或者直接删除Key让下次查询重建这样做的好处远不只是补位查询缓存原来只能缓存完全相同的SQL语句而应用层缓存可以基于业务语义设计缓存粒度同样一份商品数据字段多几个少几个、SQL里换个排序方式都能命中同一个Redis Key。而且Redis原生支持分布式多台应用服务器之间可以共享缓存这比MySQL单机的查询缓存强太多了。4.2 MySQL 8.0的线程池和Buffer Pool结合改造如果你的业务对数据库的整体并发能力不满意与其寄希望于查询缓存不如把思路放到8.0的新特性上。innodb_buffer_pool_size设置合理通常为物理内存的60%-70%热数据基本都在内存中配合innodb_buffer_pool_instances把缓冲池分成多个实例减少内部锁竞争innodb_io_capacity设为2000SSD场景让后台刷脏能力跟得上压力。这些机制加在一起比一个随时可能被写操作击穿的查询缓存可靠得多。8.0的InnoDB缓冲池本身就能缓存表和索引的数据页查询走索引定位到页直接在内存里取结果这个路径比“查一次SQL再把结果集拷贝一份存起来”轻量得多。4.3 代理层缓存ProxySQL、应用网关还有一种思路是在数据库前面加一层读写分离代理比如ProxySQL。它自带查询缓存功能且缓存粒度可以做到更细能够识别同一类查询模板把参数值替换成通配符不会因为参数值不同就缓存失效。在业务不想大改的情况下用代理层做缓存是一个折中方案。不过我不建议为了“替代查询缓存”专门引入一套代理集群毕竟加一个中间件就意味着增加一层运维负担和故障点。除非你的架构本来就需要读写分离顺手把查询缓存挂在代理层那倒是顺理成章。5. 兼容性排查如何正确面对“还能不能设置参数”的疑问5.1 误报排查看这里不是所有带“cache”的都不能用移除的是query_cache_*这个命名空间下的参数但innodb_buffer_pool_size、key_buffer_size、table_open_cache、thread_cache_size在8.0中都是合法参数很多刚接触8.0的同学看到“缓存”两个字就草木皆兵把有用的参数也给删了这反而矫枉过正。判断一个参数是否适用最权威的办法是查官方文档或者直接在MySQL里执行SHOW VARIABLES LIKE 参数名;能查到的就是当前版本支持的查不到的就是被移除或者改名的。比如SHOW VARIABLES LIKE thread_cache_size;能正常返回就说明8.0仍然保留它。5.2 老代码里的SET语句兼容处理如果你维护的老项目中有类似这样的一行代码执行SET SESSION query_cache_type ON;在5.7上可以正常运行在8.0上直接报错。处理方式分两种第一种代码能改就直接删掉这行。因为查询缓存已经没有了设置这个session变量根本没有任何意义删掉后一切都好。第二种如果代码是编译好的二进制组件或者不方便发布新版本可以做一个兼容性包装在数据库代理层过滤掉这条SET语句。比如ProxySQL的mysql_query_rules里设置一条规则把SET SESSION query_cache_type开头的语句直接丢弃DROP或者返回OKOK就能让老客户端在8.0上正常连接。还有一种更简单粗暴的做法把数据库用户隔离老模块连接专用的一个MySQL 8.0账号通过init_connect参数强制设置SET SESSION query_cache_type OFF;。但8.0里query_cache_type已经被移除这个方法只能用于5.7在8.0中无效。所以归根结底还是得靠改代码或者代理层处理。5.3 5.7和8.0开发的兼容写法如果你的开发环境是5.7生产环境已经升级到8.0测试代码里又涉及到查询缓存的设置最稳妥的做法是写一个兼容检查逻辑先探测当前MySQL版本号再决定是否执行SET语句import pymysql conn pymysql.connect(hostlocalhost, useruser, passwordpass, databasetest) cursor conn.cursor() # 判断大版本只有5.x才需要处理查询缓存相关设置 cursor.execute(SELECT VERSION()) version cursor.fetchone()[0] if version.startswith(5.): cursor.execute(SET SESSION query_cache_type OFF) # 注意5.7虽然支持query_cache_type但默认也可能被禁用这里只是示例 cursor.close() conn.close()不过这种判断逻辑属于“临时打补丁”时间长了代码里都是版本分叉维护成本很高。更推荐的做法是开发环境也直接统一到8.0不要为了模拟老版本行为而在新代码里写兼容逻辑。6. 完整解决过程实录一步一步复现处理我把一次完整的处理过程写下来方便你照着操作。场景一台CentOS服务器MySQL从5.7停机升级到8.0启动时直接报错。第一步看错误日志tail -n 50 /var/log/mysql/error.log日志里有一条很直接的记录[ERROR] [MY-000067] [Server] unknown variable query_cache_size67108864关键信息就是unknown variable后面跟着参数名意思就是当前版本不认识这个参数。第二步全盘搜索配置文件grep -rn query_cache /etc/ /etc/mysql/ /usr/my.cnf 2/dev/null搜索结果显示/etc/my.cnf里存在三行query_cache_type1 query_cache_size67108864 query_cache_limit1048576第三步备份配置文件后再修改cp /etc/my.cnf /etc/my.cnf.bak sed -i /query_cache/d /etc/my.cnf先备份再改万一改错了还能回滚别冒险直接改。第四步检查是否有其他不兼容参数。既然是从5.7升上来的顺手把整个配置里可能不兼容的项都排查一遍。重点关注sql_mode、default-authentication-plugin、innodb_file_format等。第五步重新启动systemctl restart mysqld启动成功后登录验证mysql -uroot -p mysql SHOW VARIABLES LIKE query_cache%; Empty set (0.01 sec)确认无误后再简单测试几条常用SQL确认业务功能正常。如果是新升级的实例重启后建议加一个快照备份后续出现异常还能快速回退。7. 常见问题排查速查表问题现象可能原因排查步骤解决方案启动MySQL直接报unknown variable query_cache_size配置文件残留5.7的参数grep -rn query_cache /etc/my.cnf删除或注释对应行服务能启动但应用连接报错应用或中间件初始化SQL含SET语句检查连接池的connection-init-sql、ORM配置去掉SET语句或升级中间件版本5.7升级8.0后字符集大面积乱码8.0默认字符集改为utf8mb4查看SHOW VARIABLES LIKE character_set%;在配置文件中显式指定character_set_serverutf8mb4老客户端连不上MySQL 8.0认证插件从mysql_native_password改为caching_sha2_password查看SHOW VARIABLES LIKE default_authentication_plugin;升级客户端驱动或为老用户保留mysql_native_password注1删了query_cache参数后热点查询变慢缺少了曾经的缓存层用EXPLAIN分析执行计划检查索引按4.1节加应用层缓存或优化索引与SQL修改配置文件后参数不生效改了非默认读取路径的配置文件mysqld --verbose --help查看实际读取顺序修改实际生效的配置文件然后重启确认注1这种方式仅作为过渡新环境建议直接使用caching_sha2_password老驱动适配后切换回来。补充一个容易被忽视的细节修改配置文件后必须重启MySQLSET GLOBAL即使能临时改运行时变量也无法覆盖配置文件里的静态启动参数。更关键的是query_cache_*这类被移除的参数配置文件里根本没对应运行时变量不重启等于白改服务起不来反而成了“改了没效果”的错觉根源。8. 聊聊我自己的处理习惯让这次报错以后不再出现这套流程走下来核心就是一个思路版本的升级不只是二进制替换配置文件的兼容性清理是必做功课。我个人现在再遇到Unknown system variable系列报错都会先养成立刻确认版本的习惯。不管是新装8.0还是从老版本升级第一步永远是mysql --version看清楚当前实例的大版本然后再去找配置文件的问題。这一步能省掉大量无效排查。另外处理完query_cache_size之后建议顺手把所有来自旧版本的配置项整体过一遍。我在实际操作中发现过很多次一个环境里残留的旧参数往往不止一个两个一起处理掉既能解决当前的启动报错还能规避后续业务上线时的隐性故障。最后说一个加分项在升级或整改结束后养成把干净可用的my.cnf归档保存的习惯。下次再碰到新环境需要初始化直接把这份已经验证过的配置拿过去改改路径就能用比从网上东拼西凑一份配置再慢慢调省力得多。
